[IDEA] [2020] Migrate to ES modules

[Leilei332]

[!NOTE] Edit: It turned out that export requires 2018 baseline, so this issue targets future tiddlywiki versions that support 2020 baseline.

With the support of ES2017, I think we can starting to migrate modules to be ES modules, which is modern and has many benefits.

According to nodejs docs, require() supports loading synchronous ES modules, while currently all of the core modules are synchronous. So IMO we are ready to migrate to ES modules now.

There exists one major issue: some core modules uses dynamic require() to make them both support nodejs and browser. There only exists one asynchronous alternative supported by ES: import(), which requires 2020 baseline.

See: https://nodejs.org/api/esm.html

[Jermolene]

Thanks @Leilei332 that reminds me of a similar issue which I've documented in #9450

[pmario]

... which is modern and has many benefits.

What are the benefits? --- Other than browsers support it now. The main problem is, that all our modules need to work in the browser and Node.js alike, without any changes.

At the moment we do not need any complex wrapper code and additional build steps to make our Node.js modules work with the browser. They just work with code that comes from tiddlers.

IMO import makes sense if the code is loaded dynamically form the server. We do not have a server. Our code is fully loaded at startup. Even if we have a Node.js backend, the code is still loaded at once, to maintain SPA behaviour.

Tree shaking is not possible for our libraries, since we need full functionality all the time, because 3rd party plugins may use code, that may be removed by "tree shaking".

[buggyj]

require() would still be needed for third party plugins.

[Jermolene]

There exists one major issue: some core modules uses dynamic require() to make them both support nodejs and browser. There only exists one asynchronous alternative supported by ES: import(), which requires 2020 baseline.

Have you got a list of those usages? Might it be viable to refactor them into static imports?

[buggyj]

Maybe I do not understand what is being proposed. Tiddlywiki implements its own require() for browser support, is the idea

a) to replace the interface

b)leave the require() interface and change its implementation

[Leilei332]

There exists one major issue: some core modules uses dynamic require() to make them both support nodejs and browser. There only exists one asynchronous alternative supported by ES: import(), which requires 2020 baseline.

Have you got a list of those usages? Might it be viable to refactor them into static imports?

Though I don't have a full list of these usages, I did create two PRs recently to refactor some of them: #9488 #9475. With the implementation of #9183, I think we should write separate code for separate platforms. IMO making one code support both platforms is problematic and hard to maintain.

[pmario]

I think we should write separate code for separate platforms. IMO making one code support both platforms is problematic and hard to maintain.

I think the contrary is true. Having to change code in 2 files for a change that is the same on both platforms is error prone and hard to maintain.

[Leilei332]

I think we should write separate code for separate platforms. IMO making one code support both platforms is problematic and hard to maintain.

I think the contrary is true. Having to change code in 2 files for a change that is the same on both platforms is error prone and hard to maintain.

It's true for codes that are similar. But if two platforms uses different libraries or different APIs, spliting them into two files makes sense and reduces maintainence burden.