Skip to content

fix: make "url" optional in resolver created with createResolve#44

Merged
pi0 merged 1 commit into
unjs:mainfrom
rchl:fix/create-resolve
Jun 16, 2022
Merged

fix: make "url" optional in resolver created with createResolve#44
pi0 merged 1 commit into
unjs:mainfrom
rchl:fix/create-resolve

Conversation

@rchl

@rchl rchl commented Apr 29, 2022

Copy link
Copy Markdown
Contributor
  • The type of the url argument to resolver created with createResolve is made optional. The point is that the defaults are used and the url doesn't have to be provided, same as in Node's import.meta.resolve API.
  • Enable checkJS so that the *.mjs files in test/fixture are least type checked (mostly for the editor's sake).
  • Add mlly path mapping in tsconfig.json so that there are no errors reported in test/fixture when importing from mlly.

Comment thread src/resolve.ts
export function createResolve (defaults?: ResolveOptions) {
return (id, url) => {
return (id: string, url?: ResolveOptions['url']) => {
return resolve(id, { url, ...defaults })

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've also noticed that the logic here is incorrect as the defaults will override the url even when it is explicitly provided. I didn't want to mix that fix in into this one but I can create a follow-up PR for that.

Comment thread test/fixture/resolve.mjs
Comment on lines +3 to +4
const resolve = createResolve({ url: import.meta.url })
console.log(await resolve('./cjs.mjs'))

@rchl rchl Apr 29, 2022

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see that those test files are not really used for anything right now (which is a shame because it would have caught an issue otherwise) but I've changed this to create a local variable rather than assigning to import.meta.resolve as import.meta.resolve has its own type already (coming from Node) so even though it's our custom resolver, it has still used the Node type and thus wouldn't check type issues if those would be inconsistent.

@danielroe danielroe requested a review from pi0 June 9, 2022 12:04
@pi0 pi0 merged commit 7c1bda4 into unjs:main Jun 16, 2022
@rchl rchl deleted the fix/create-resolve branch June 17, 2022 06:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants