I have already specified it in the code as a dynamic import that should not be transformed

Why do you think so? There are a lot of optimizations async modules via import(...), so you just lose them

Other bundlers do the same. Also you can have multiple @ant-design/cssinjs impots - dynamic and async, what we should do here if we should leave import as is? I just want to say the function notation provide the real power. If you need more arguments in callback for checks just provide infromation what will help you

I have already specified it in the code as a dynamic import that should not be transformed

Why do you think so? There are a lot of optimizations async modules via import(...), so you just lose them

Other bundlers do the same. Also you can have multiple @ant-design/cssinjs impots - dynamic and async, what we should do here if we should leave import as is? I just want to say the function notation provide the real power. If you need more arguments in callback for checks just provide infromation what will help you

I have the impression that @ntucker has the exact same question that I have in mind right now:
Is webpack able to leave certain module inclusions as-is?

Consider I have the following .js code:

import { MyClass } from "./MyClass.js";
import { createRequire } from "node:module";
import rescape from "@stdlib/utils-escape-regexp-string"; // this is a commonjs module

const path = createRequire(new URL(".", import.meta.url))("node:path"); // explicitly include `node:path` using the `require`-mechanism
rescape(`${new MyClass()}`);
(await import("inquirer")).default([]);

Consider I want inquirer, node:module, @stdlib/utils-escape/regexp-string and node:path to be externals.
Is there some way for me to specify that webpack shouldn't touch the expressions I am using for including the modules?`

Meaning:

• ./MyClass.js should be bundled
• node:module should be imported
• @stdlib/utils-escape-regexp-string should be imported (commonjs are treated as if they were ESModules with default exports)
• node:path should be required using createRequire
• inquirer should be dynamically imported

Is there some way for me to reach this goal without having to specify the nature of the inclusion expression for each module?

@alexander-akait

I think you're assuming a web application target? Not library and not nodejs? If webpack should not support those, there shouldn't be multiple docs pages on them.

Otherwise, your comments don't make sense to me.

There are a lot of optimizations async modules via import(...), so you just lose them

Node: I don't consider hoisting a require() on an optional package to top level being an optimization. This means the first import will fail and nothing will work. It is in fact breaking, and defeats the entire purpose of using a dynamic import to begin with. Additionally, forcing parsing of all javascript up-front is an anti-optimization and increases startup times and memory usage.

Library: Diabling the ability of library consumers to use these optimizations DISABLES optimizations. So it is in fact better to keep these in place so they can be optimized properly.

Other bundlers do the same

No rollup works fine and doesn't break this. However, I'd like to use webpack for everything as it has a better ecosystem and I can share things with my application bundler.

what we should do here if we should leave import as is

I don't understand the nature of the question - you answered it yourself: 'leave import as is'. Obviously I'm not implying we should do this for web application bundling if that's what you're implying. Externals are definitely a thing in webpack.

I just want to say the function notation provide the real power. If you need more arguments in callback for checks just provide infromation what will help you

Can you elaborate on what this is? Maybe there are docs links that explain more? I don't know what 'function notation' is in this context.

@manuth @ntucker

Can you elaborate on what this is? Maybe there are docs links that explain more? I don't know what 'function notation' is in this context.

Using function to describe cases and please. And please be more calm, because I get the feeling that you are not trying to constructively talk, but to prove to me that I am a fool and wrong.

Then let's go to the list of current problems point by point, because I see a lot of different things here, and it's hard to answer what exactly this could be achieved and how better. Can you summarize in table - what do you have and how it should be load externally.

We have a wide range of opportunities for externals and it's pretty hard to find something in common for everyone, I can put a lot of links here with incredibly different requests and statements that this is how it should work.

I’m not saying that we can’t improve it, I just want to reach an understanding of what exactly is broken at the moment or it’s not possible to configure it without problem. So can we summarize, many things already support, so maybe we can just do better defaults or provide an option to enable such defaults

@manuth @ntucker

Can you elaborate on what this is? Maybe there are docs links that explain more? I don't know what 'function notation' is in this context.

Using function to describe cases and please. And please be more calm, because I get the feeling that you are not trying to constructively talk, but to prove to me that I am a fool and wrong.

Then let's go to the list of current problems point by point, because I see a lot of different things here, and it's hard to answer what exactly this could be achieved and how better. Can you summarize in table - what do you have and how it should be load externally.

We have a wide range of opportunities for externals and it's pretty hard to find something in common for everyone, I can put a lot of links here with incredibly different requests and statements that this is how it should work.

I’m not saying that we can’t improve it, I just want to reach an understanding of what exactly is broken at the moment or it’s not possible to configure it without problem. So can we summarize, many things already support, so maybe we can just do better defaults or provide an option to enable such defaults

Thank you so much for hearing me out - I'll write a separate answer in this discussion as I don't think me and @ntucker are talking about the same thing.

I'm afraid not, do you want only certain packages to be untouched? Or every import ... from ...? Also what is your final output type - library or application?

Thanks for coming back at me!
My final output type would be an npm module - so library, I guess.
Thus, I'd like to have any npm dependencies located under node_modules to be external and to have full control over what kind of inclusion statement is emitted (as in keep the statements as they were).

But I think webpack is rather focused on bundling apps for the web - as its included in the name.
So I'm totally fine if there's no way of getting this behaviour realized.

I would like to have full control over which packages are left untouched, yeah, and I am targetting a web application. I don't see why this couldn't be realized.