You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I think having the default target to be reliant on process.versions.node creates a lot of inconsistency especially if you use a multitude of environments such as local and CI.
To fit closer to the paradigm of zero-config, it might be better for the bundler to default to Node LTS instead for best practices.
I'm not sure if this should be considered a breaking change considering the existing setup already led to inconsistent bundles.
The text was updated successfully, but these errors were encountered:
I'm OK with that but we'll need a trusted API to get the latest Node version. Ideally an npm package that contains Node.js versions or something so that there's no loading time during build.
Isn't it just changing this line here from node${process.versions.node} to node14. Or am I missing something here? I'll be happy to PR it just to start getting my hands involved with this repo if that's the case.
I do think we should manually set the target and update the LTS target versions ourselves, so every time the default target changes we can mark it as a breaking change.
I think having the default target to be reliant on
process.versions.node
creates a lot of inconsistency especially if you use a multitude of environments such as local and CI.To fit closer to the paradigm of zero-config, it might be better for the bundler to default to Node LTS instead for best practices.
I'm not sure if this should be considered a breaking change considering the existing setup already led to inconsistent bundles.
The text was updated successfully, but these errors were encountered: