-
Notifications
You must be signed in to change notification settings - Fork 5.4k
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 our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Supporting extension-less module resolution #857
Comments
Yes I ageee - we can support it to help adoption - but I think the code/docs should be heavily commented that it’s meant as a stop gap solution. |
Note that Node.js itself is currently in the process of considering if this should be removed entirely. There have also been issues with ".mjs" and ".js" extensions both being checked as well causing instance issues with libraries such as GraphQL which seems to also be leading in the direction of remaining explicit. For what it is worth, my opinion currently is that we should mandate extensions for modules, as a resolver that doesn't touch the file system is a fast resolver. |
Bumped versions for 0.301.0 Co-authored-by: bartlomieju <bartlomieju@users.noreply.github.com> Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
Supporting extension-less module resolution should be considered for Deno. It would help adoption, specifically because it would allow authoring of local code in editors with full "out of the box" TypeScript support.
Resolution
This would likely require Deno to attempt to resolve modules in a specific order, applying the extensions. For example:
./foo/bar
/foo/bar.ts
/foo/bar.js
And:
https://example.com/foo/bar
https://example.com/foo/bar.ts
https://example.com/foo/bar.js
This could become very costly for remote modules.
Other considerations
Currently Deno doesn't support any sort of "magical" resolution of things like
./foo/bar
resolving to./foo/bar/index.ts
and IIRC was part of Ryan's "10 things I did wrong" list. On the other hand, TypeScript, when using in an editor, would follow a module resolution like that. It also has a few other "magical" resolution in line with NodeJS, like namespace resolutions which Deno does not support.A lot of userland code likely could be already transpiled TypeScript with a
.d.ts
file and a.js
file. It might be worth considering if Deno would add the feature to then type check that code before running it.Related to #852
The text was updated successfully, but these errors were encountered: