Issue 1:
Feature request

I am not 100% sure if this still fits the scope of the webpack project.

I am working on the topic "Expanding Single Page Apps into multiple Browser Windows", which can look like this:

Quick background info:

Apps we create using neo.mjs just import the main thread. The main thread creates the app, data & vdom workers. The only important part here is the app worker: you define which app (entrypoint) you want to use and the app worker dynamically imports it.

For the dist versions which rely on webpack, webpack has no chance to know what could get imported, so I created build specific entrypoints.

Example:

https://github.com/neomjs/neo/blob/master/buildScripts/webpack/entrypoints/myApps/Covid.mjs

import '../../../../src/worker/App.mjs';
import '../../../../apps/covid/app.mjs';

This cheating a little bit, since inside the dist versions, the import is no longer dynamic.

Works fine though.

Now for the multi Browser Window apps, i needed to switch the App (,Data & VDom) workers into SharedWorkers.

It does work fine using webpack based builds as long as you use only 1 app:

Online Demo: https://neomjs.github.io/pages/node_modules/neo.mjs/dist/development/apps/sharedcovid/index.html#mainview=table

More background infos:

https://medium.com/swlh/neo-mjs-v1-2-5-support-for-sharedworkers-including-firefox-b31f144cea3f?source=friends_link&sk=6bd4d0beb0e095c388153ce8f06aa76f

I got a version using multiple Apps running directly inside Chrome (using JS modules inside the browser) and it would be nice if it would be possible to achieve the same result with a webpack based build.

Now this is the tricky part:

SharedWorkers have to use the same file as an entry point (otherwise the browser will spawn new SW instances, which makes using them pointless).

To make this happen, we need to use separate webpack based builds (Shared AppWorker VS apps), which can work in combination.

What is the expected behavior?

https://www.youtube.com/watch?v=RslY-e-f_qc

It would be nice if this app could run the same way it does in dev mode (without any builds).

What is motivation or use case for adding/changing the behavior?

SharedWorkers are a big deal, even the webkit team is finally thinking about supporting them:

https://bugs.webkit.org/show_bug.cgi?id=149850

This has a big potential to improve the way, UI development works in general.

How should this be implemented in your opinion?

I have been thinking about this quite a bit.

For the neo.mjs context, we should create a separate webpack based build just for sharedthe app worker (not including apps).

Then, to build apps, we need separate builds (entry points for builds).

I was thinking about something like:

import '../../../../src/worker/App.mjs';

import(/* webpackChunkName: 'apps/sharedcovid/app' */ '../../../../apps/sharedcovid/app.mjs');
import(/* webpackChunkName: 'apps/sharedcovid_chart/app' */ '../../../../apps/sharedcovid_chart/app.mjs');
import(/* webpackChunkName: 'apps/sharedcovid_helix/app' */ '../../../../apps/sharedcovid_helix/app.mjs');
import(/* webpackChunkName: 'apps/sharedcovid_map/app' */ '../../../../apps/sharedcovid_map/app.mjs');

This way, the app worker will get parsed as well for each app build to ensure that we don't duplicate modules inside the app worker and apps (especially duplicating the IdGenerator would break a lot).

We can adjust output: {filename: chunkData => {}}

to save the app worker output itself for an app build into a not used dummy chunk (e.g. 0.js or tmp.js).

we can use split chunks for app related code this way (multiple dynamic imports which are supposed to not duplicate code).

I tried this approach, but am getting errors. E.g. since we are not using the "real" entry point, the build app worker output is not able to pick up the app chunks (webpack_require.e is undefined, since the separate app worker output is no longer exposing dynamic imports to webpack).

Are you willing to work on this yourself?

I don't have much time at the moment (still polishing the content of the first shared workers demo to expand SPAs into multiple browser windows), but am willing to help a bit and can definitely provide more input if needed.

Issue 2:
Feature request

What is the expected behavior?

For TypeScript's new nodenext module resolution (which is still in nightly build), we are required to write a full file name including extension like:

import {foo} from './foo.js';

Even though we have a source code foo.ts or foo.tsx, the file extension on import statement is .js, this results webpack to fail with errors like:

error in ./src/index.tsx

Module not found: Error: Can't resolve './Boundary.js' in '/Users/otakustay/Develop/react-suspense-boundary/src'

What is motivation or use case for adding/changing the behavior?

We need to satisfy TypeScript's coming nodenext module resolution and be compatible with pure ESM resolve rules

How should this be implemented in your opinion?

Make .js a special case that on resolve webpack could remove the .js part and then do a normal resolve

Another solution is to make resolve.fallback a function so that we can remove .js part before webpack do it's resolve

Are you willing to work on this yourself?

not familiar with this