Comments (10)
Are we meeting today?
Yes
from loaders.
@JakobJingleheimer and I chatted. I didn’t record it because it was just us and I don’t think there’s much point in making a “team” decision as two people. But basically we both like the proposal in nodejs/node#49432, and want to try to get it implemented and landed before 21.0.0. We think it shouldn’t be split up into many small flags. @LiviaMedeiros is this something you want to collaborate on?
from loaders.
Adding nodejs/node#49432 to the agenda. @LiviaMedeiros, could you join us in this meeting?
from loaders.
No; I'll probably watch it next morning. Unless there are any specific questions for the agenda, most of my objections are already outlined in prior discussions anyway.
from loaders.
No; I'll probably watch it next morning. Unless there are any specific questions for the agenda, most of my objections are already outlined in prior discussions anyway.
I'm hoping that we can reach a consensus on what to do regarding that proposal. I'd appreciate your input in that discussion. If we decide something and you don't like our conclusion, what then?
Is there a better time that would work for you?
from loaders.
Are we meeting today?
from loaders.
Is there a better time that would work for you?
Sorry for very late response and/or inconvenience; I can't attend. Please proceed without me at the time that is convenient for others.
from loaders.
I have a sudden conflict, moving the meeting 30 min later. Anyone planning to join besides me and @JakobJingleheimer ?
from loaders.
I'm not quite sure yet and can't promise anything.
First of all, my opinion that nodejs/node#49531 should go separately still stays, until there is convincing reason to not (I think, correct code behaviour outweights any subjective preferences, even if preferences are understandable and reasonable) or TSC resolution.
As for nodejs/node#49432
- My objection about URL part is completely lifted if the part is removed from proposal.
If it's changed into rework of how--import
works, I'd like to see if there is consensus on how it should work, consensus on implied breaking changes, and consensus on if the changes would work with that proposal (for example, the latest messages propose to make--interactive
behave differently depending on the esm flag, which is questionable). - My objection about limitation to
--import
is lifted because it's no longer a limitation.
Because the solution for making it non-breaking for ecosystem seems to be "it won't work inside of node_modules
", I'm concerned about performance implications. This kind of check is very expensive. We can accept it as trade-off when it's an experimental flag, but if the plan is to make it eventually work by default, I'm afraid that we will end up with significant regression that we can't work around without breaking ecosystem.
Thus said, I think the main idea of nodejs/node#49432 is feasible but it has too much vagueness right now. Not really a fan of knowingly implementing UB and only then thinking how to fix it; I'd prefer if we had clear detailed image of what we need to achieve and only then start implementing it.
from loaders.
First of all, my opinion that nodejs/node#49531 should go separately still stays, until there is convincing reason to not (I think, correct code behaviour outweights any subjective preferences, even if preferences are understandable and reasonable) or TSC resolution.
As I wrote in nodejs/node#49531 (review), I think the “everything” flag needs to land first, but once that’s landed then I think nodejs/node#49629, the unflagged version of enabling extensionless files in module
scope, can probably land. I say “probably” because we should allow at least a few weeks after the first PR landing to see if anyone reports issues before we land the follow-up, especially if the follow-up is unflagged. The reason for this ordering is to manage user expectations; I think the vast majority of users care about extensionless files outside of package scopes, rather than within module
scope, so if we land the module
scope one first we’re likely to get complaints that we didn’t solve the problem for loose extensionless files.
- My objection about URL part is completely lifted if the part is removed from proposal.
@aduh95 raised a few points about this too and I’m now curious to see if a different approach might be preferable (the --import
idea). I can either take it out of the proposal or just leave it out of the first PR, and it can either land as a standalone separate thing (if we do --import
) or a follow-up additional behavior determined by the big flag, or just drop it. This flag will be experimental for likely the entire lifetime of 21.x, October through April, so we’ll have plenty of time to refine what it does.
Because the solution for making it non-breaking for ecosystem seems to be “it won’t work inside of
node_modules
“, I’m concerned about performance implications. This kind of check is very expensive.
I’m pretty sure we’re already paying the cost for this check because currently both the ESM and CommonJS loaders search for the nearest parent package.json
for every .js
file. It would do the same for extensionless files, but a) they’re a lot less common than .js
files, and b) they shouldn’t be any more expensive to load than .js
files.
Not really a fan of knowingly implementing UB and only then thinking how to fix it; I’d prefer if we had clear detailed image of what we need to achieve and only then start implementing it.
What do you mean by this?
from loaders.
Related Issues (20)
- Loaders allow breaking JS spec invariants HOT 16
- Official `fs` overlay HOT 3
- Node.js Loaders Team Meeting 2023-11-21
- bug: CJS exports analysis reads directly from disk HOT 7
- Node.js Loaders Team Meeting 2023-12-05 HOT 9
- Node.js Loaders Team Meeting 2023-12-19
- Bad coverage information when loaders are used
- Node.js Loaders Team Meeting 2024-01-02
- Node.js Loaders Team Meeting 2024-01-16 HOT 2
- improve registration HOT 2
- Node.js Loaders Team Meeting 2024-01-30 HOT 3
- --experimental-loader breaks in Node 18.19 HOT 5
- Node.js Loaders Team Meeting 2024-02-13 HOT 1
- Node.js Loaders Team Meeting 2024-02-27 HOT 2
- Node.js Loaders Team Meeting 2024-03-12 HOT 1
- Node.js Loaders Team Meeting 2024-03-26 HOT 1
- Node.js Loaders Team Meeting 2024-04-09 HOT 15
- Node.js Loaders Team Meeting 2024-04-13
- Node.js Loaders Team Meeting 2024-04-23 HOT 3
- Node.js Loaders Team Meeting 2024-05-07 HOT 3
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 loaders.