Import Statements

[ElectronicsArchiver]

Hi, I'm currently refactoring some package code and thought I'd try
to make it use import statments, however it did not at all work out.

I'm getting the typical 'Can't use import statements outside module'
error, however I have done basically everything I could think off to
ensure that it should be working:

• Using pulsar --test spec instead of atom --test spec

• Pulsar should support it with node version > 14?

• As a side note, when will Pulsars dependencies be updated?

  • Electron : 12.2.3
  • Chrome : 89.0.4389.128
  • Node : 14.16.0

  Impressively old versions..

• Added "type" : "modules"

• Tried using .mjs to force it, even if it would have worked,
  wouldn't be an option since the spec file is not regonized
  if it doesn't have a .js extension.

[confused-Techie]

I'll let someone that's more familiar with the Core editor touch on the major reason of your discussion.

But as for when will we update our versions, keep in mind that when Atom was announced to sunset they were using Electron 9 I think? And the Node and Chrome versions that were compatible with it. It was only on their last update which we don't have did they upgrade further and break a lot in the process.

We are hard at work getting these updated, as that is one of our biggest focuses right now.

But to upgrade any further our Native Modules need to be context aware (basically rewrite most of them) and that is our biggest blocker.

So I can't provide any estimate of when that might happen, but if you'd like to see it soon I'd recommend checking out any of our Native Modules and helping to rewrite them to be context aware to get us there. Once they are we plan to jump all the way to Electron 19 if we can.

[ElectronicsArchiver]

Context aware means basically no global state in a required file?

[ElectronicsArchiver]

However you can still have code that creates state
that isn't changed or removed by any instance right?

For example generating a list of idk.. css classes?

[mauricioszabo]

Context aware also means we can't use memcpy and other direct memory access on native modules.

Currently, two core libraries use this - superstring and tree-sitter. We're thinking about migrating both to WASM, as tree-sitter is actually really hard to replace considering that all grammars also need to be context aware, and as of now none are...

[ElectronicsArchiver]

Oh wow, that sounds .. great .. how did Atom even hold up before this?

[mauricioszabo]

Well, context awareness is a newer thing, it basically started to be required after Microsoft bought GitHub so there was no effort to really make things work on newer Electron...

[Daeraxa]

As a side note, when will Pulsars dependencies be updated?

There is active work to get it to > Electron 12.

This isn't simple as native modules now need to be context aware so it basically breaks nearly everything. Check out https://github.com/pulsar-edit/pulsar/tree/bump-electron-19-with-async-superstring if you want.

[meadowsys]

Requires aren't going anywhere, so I don't think there should be any rush to update them until the editor is in a more stable place

edit: To clarify, I mean require as a module system and a function isn't going anywhere out of node

[sertonix]

The base problem is that commonjs loading is sync and module loading is async. So require (sync) can only load commonjs and import (async) can only load modules. And since import is not used kn the core you can't load modules as the main file from a package.
You might be able to create a package with a commonjs entrypoint that then uses dynamic import to load a module.

[mauricioszabo]

Let's be honest? The base problem is that Javascript have zero regards for backwards compatibility.

But there may be a way. We're studying handling some special cases on package management, add support for "metapackages" (packages that are bundles of other packages) etc. This will probably trigger a partial rewrite of package management, specially the part that imports packages. We may be able to replace the require that Pulsar uses with import(...).then, and asynchronously import things.

May be being the keyword here - there are some stuff that Pulsar does to transpile some packages "on the fly", and that basically uses some undocumented/deprecated features on Node.JS. I'm not sure ESM implements the same features, so while this can work, this can also mean we won't be able to require current packages that depend on this feature.

Or... we can try to mark a package that depends on the pulsar engine instead of the atom engine. This way we can reimplement the whole package management system at will, and keep the old one as a "compatiblity layer" that does not support ESM and does all transpilation 🤔

[sertonix]

Don't replace require with import! Then CommonJS doesn't work anymore (wich would mean breaking all packages).
The package manager needs to use import if the package is a module. And that can be read from the package.json.

[confused-Techie]

Yeah I'd vote if trying to add this feature during the partial rewrite of package management. Could we make it dynamic? Read's the package.json first and uses require by default but if the package specifies type: module then it could use import? Obviously a bit more complex to try and use both but would be really cool if possible

[mauricioszabo]

@sertonix import is compatible with CommonJS (the async command import, not the special syntax). It just resolves asynchronously