Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

feat: resolve Svelte components using TS from exports map#2478

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Draft
dummdidumm wants to merge10 commits intomaster
base:master
Choose a base branch
Loading
fromexports-map-resolution

Conversation

dummdidumm
Copy link
Member

@dummdidummdummdidumm commentedAug 28, 2024•
edited
Loading

This change allows people to write export maps using only asvelte condition (and notypes condition) and still have the types for their components resolved (i.e. the import is found) as long as they use TypeScript (i.e. have lang="ts" attribute) inside it. This should help people using monorepo setups with strong typings and not wanting to provide d.ts files alongside.

This is achieved doing three adjustments:

  • addcustomConditions: ['svelte'] to the compiler options, so that TypeScript's resolution algorithm takes it into account
  • ensure that Svelte files have a module kind of ESM, so that TypeScript's resolution algorithm goes into the right branches no longer needed since the switch to using.d.svelte.ts as the "virtual file check" entry point
  • deal with.d.svelte.ts files in the context of an exports map, because that's what TypeScript will try to resolve this to in the end

This is also related to#1056 insofar that we align with TypeScript for this new capability: We don't resolve the file if it's a component not using TypeScript (i.e. not having the lang="ts" tag), similar to how TypeScript does not resolve .js files within node_modules

As a side effect, this is a major version bump for language-tools and the typescript plugin, and consequently for svelte-check/vs code extension

xeho91 and gyurielf reacted with eyes emoji
This change allows people to write export maps using only a `svelte` condition (and no `types` condition) and still have the types for their components resolved (i.e. the import is found) as long as they use TypeScript (i.e. have lang="ts" attribute) inside it. This should help people using monorepo setups with strong typings and not wanting to provide d.ts files alongside.This is achieved doing three adjustments:- add `customConditions: ['svelte']` to the compiler options, so that TypeScript's resolution algorithm takes it into account- ensure that Svelte files have a module kind of ESM, so that TypeScript's resolution algorithm goes into the right branches- deal with `.d.svelte.ts` files in the context of an exports map, because that's what TypeScript will try to resolve this to in the endThis is also related to#1056 insofar that we align with TypeScript for this new capability: We don't resolve the file if it's a component not using TypeScript (i.e. not having the lang="ts" tag), similar to how TypeScript does not resolve .js files within node_modules
@dummdidumm
Copy link
MemberAuthor

Mhm not sure why this fails - works locally for me (Windows)

@jasonlyu123
Copy link
Member

I didn't see the package.json with exportMap. Maybe it's ignored because of gitignore? About.d.svelte.ts, this isn't exclusive to export maps import. TypeScript would also try this with relative import. Not sure if anyone uses it to override the type definition of the svelte file. This will change the resolved module from the .d.svelte.ts to the actual svelte file.

@dummdidumm
Copy link
MemberAuthor

Doh, you're right, the node modules folder isn't checked in.
Good point about the files - theoretically can happen for svelte.ts, too. I'll look into it

@dummdidumm
Copy link
MemberAuthor

I realized that since 5.0, TypeScript will check ford.svelte.ts first before checking.svelte.ts etc - which we can take to our advantage to do the following:

  • be less exposed to the danger of clashing with a real.svelte.ts file (in Svelte 5 this will be more common)
  • when doingimport Foo from './foo.svelte,foo.svelte will now take precedence over a siblingfoo.svelte.ts file. You can import that sibling by doingimport { foo } from './foo.svelte.js'. It's definitely discouraged to have files with the same name, but it's possible now. Strictly speaking this is a breaking change because the order is different now

@dummdidumm
Copy link
MemberAuthor

dummdidumm commentedAug 30, 2024•
edited
Loading

Having second thoughts about this - should we really do this? It could encourage bad patterns. On the other hand we could also embrace it - I'm not sure. This needs discussion with other maintainers.

Implementation-wise I noticed that the TS plugin does throw an error:Module 'package' was resolved to '[redacted]/node_modules/package/foo.svelte', but '--allowArbitraryExtensions' is not set.ts(6263) - not sure if there's a way to get around this, which would also be a problem for this PR.

I'm gonna split out the other changes to land them and put this into draft.

@dummdidummdummdidumm marked this pull request as draftAugust 30, 2024 12:43
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Reviewers

@jasonlyu123jasonlyu123jasonlyu123 approved these changes

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

2 participants
@dummdidumm@jasonlyu123
[8]ページ先頭
©2009-2025 Movatter.jp