Modules: vscode has no plans to address esm modules in the foreseeable future

Created on 31 Oct 2019  路  7Comments  路  Source: nodejs/modules

this seems a consideration in unflagging --experimental-modules.

https://github.com/microsoft/vscode/issues/77871

this may be well known and being addressed but i just ran into it.

my particular configuration:

My system:
node: '12.11.1'
v8: '7.7.299.11-node.12'

vscode:
Version: 1.39.2
Commit: 6ab598523be7a800d7f3eb4d92d7ab9a66069390
Date: 2019-10-15T15:33:40.634Z
Electron: 4.2.10
Chrome: 69.0.3497.128
Node.js: 12.11.1
V8: 6.9.427.31-electron.0
OS: Linux x64 4.15.0-66-generic

Most helpful comment

But this just seems to be
an electron bug (?) where it looks at NODE_OPTIONS set in the user profile
which i suspect is almost never what a user expects.

A quick test of shoving NODE_OPTIONS="--experimental-modules" into .zshrc does indeed break VSCode (it just fails to open) if opened from the same shell.

This breaks VSCode today irrespective of unflagging, so I don't think there's really anything to do here other than advise people not to set NODE_OPTIONS in their shells (or auto loaded configs) if they're using Electron apps.

All 7 comments

How is this an issue? Once the flag is no longer required won't this no longer be a problem?

I think they're saying vscode will fail to start once we remove the flag. However, vscode will have presumably tested and fixed this by the time they ship a version of vscode with that version of node.

I think this issue goes beyond the modules flag. Reading the issue title I thought it was about ES modules support in code. But this just seems to be an electron bug (?) where it looks at NODE_OPTIONS set in the user profile which i suspect is almost never what a user expects.

But this just seems to be
an electron bug (?) where it looks at NODE_OPTIONS set in the user profile
which i suspect is almost never what a user expects.

A quick test of shoving NODE_OPTIONS="--experimental-modules" into .zshrc does indeed break VSCode (it just fails to open) if opened from the same shell.

This breaks VSCode today irrespective of unflagging, so I don't think there's really anything to do here other than advise people not to set NODE_OPTIONS in their shells (or auto loaded configs) if they're using Electron apps.

The issue I was trying to float (sorry I wasn't more clear) is that vscode doesn't handle ESM modules being enabled. That's not an issue now because it requires the user to turn them on via NODE_OPTIONS but, if unflagged, vscode will not run.

I set NODE_OPTIONS at the bash command prompt, not in the vscode user options, similar to what @Jamesernator did with zsh.

I can file an issue with vscode that modules are likely to be unflagged and that they may want to fix the issue. Does that make sense?

If Code is an Electron app, doesn't that mean it bundles its own Node runtime? So they can upgrade that whenever they resolve this bug.

yes, it's an electron app. good point - they won't see the --experimental-modules flag if that becomes the default; they're running their own node runtime; no problem.

thanks.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

arlac77 picture arlac77  路  3Comments

devsnek picture devsnek  路  3Comments

GeoffreyBooth picture GeoffreyBooth  路  4Comments

MylesBorins picture MylesBorins  路  4Comments

SMotaal picture SMotaal  路  5Comments