Comments (6)
There are already so much "unstable" flags available, that I would try to avoid another one, whenever possible.
But it would be very appreciable, if we could have a central detection mechanism -- including something similar to nodejs/node#50096 resp. its containsModuleSyntax
check -- to prevent unnecessary duplication of this kind of decision-making.
Right now deno
is handling this kind of detection/decision task at a few different places.
That's why I'm fighting in #22840 some node:worker_thread
import related troubles, which look surprisingly similar to #22811, which you solved just recently.
Please could you take a scrutinizing look at my draft PR (#22841) to solve this issue in this other place as well. Nevertheless, a more general solution for the file type detection and more reliable unit tests for its proper application would indeed make a lot of sense in the long run.
from deno.
encourages people shipping and writing code that doesn't work with Node's resolution
Upon further reflection, what I said in my previous comment isn't as relevant to Deno because Deno already treats everything outside node_modules as an ES module, so someone could already develop an npm package without properly setting up their package.json for distribution for Node.
I opened #22945 that implements this behaviour without a flag.
from deno.
I would also prefer this to be handled automatically, same as Bun does, and for sure Node would also do this as soon they stabilize their experimental flag described here.
from deno.
Once Node does that then we'll also change the behaviour to align with Node, but doing non-standard Node behaviour for Node compat makes the ESM/CJS situation in the Node ecosystem worse and not better (encourages people shipping and writing code that doesn't work with Node's resolution). I understand it's convenient for apps to have this behaviour though, which is why this non-standard Node behaviour will most likely be behind a flag.
from deno.
In this particular case we just have to figure out, which kind of import format should be used for a particular file. This can be simply decided by 1. the suffix, 2. enclosing package.json
metadata or 3. found ESM/CJS specific keywords within the file.
We just have to figure out one question: how to handle the given files in the most appropriate manner?
If none of this criteria fits, we can still fall back to some very old fashioned defaults...
A perfect emulation of all the faults, inflexibility and historic burden of node
shouldn't be the goal. Concerning ESM support in particular, we should really try to handle these tasks simply better than in node
and also strive for unchanged legacy code utilization in modern runtimes --i.e. the other side of compatibility and easy reuse -- wherever possible.
from deno.
I'm in the processing of writing a more extensive answer about this topic in #17650.
We have very likely slightly different opinions on this topic, but I really like the way how you tireless advocate for improvement and practical change! :)
from deno.
Related Issues (20)
- ext/node: script exits when it shouldn't HOT 2
- node:module register is not a function HOT 1
- `@deno-types` does not work with `async import()` HOT 2
- `@deno-types` does not work with `async import()` HOT 2
- DENO_FUTURE=1 should remove deprecated TypeScript types HOT 2
- Lockfile v4
- `deno add` - Failed updating config file due to no object
- `deno add` - support `http:` and `https:` specifiers HOT 5
- Using `deno add` then importing dep in jupyter notebook does not take new deno.json into account
- deno.jsonc isn't used for checking JSX element HOT 5
- Measure impact of snapshot using `--serialization-statistics` HOT 1
- Network services should preferentially bind to IPv4
- SSE no events sent when server is running HOT 1
- Deno crashes on startup within container HOT 3
- Consider asynchronously caching statically analyzable dynamic imports in the background for `deno run` instead of up front
- Support TLS SNI on listenTls and serve
- suggestion: undeprecate `--unstable` flag
- Getting different output in local CLI and Deno Deploy HOT 3
- Misleading recommendation for permissions when using compiled binary
- Deno read and write permission flags not work on Deno compile with Deno KV
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from deno.