How should we handle import.meta #6719
Comments
|
I actually don't think It is mostly useful for things that are actually not global but still need to exist in every module anyway; for example their own filename, or even the In webpack's use case, it'd be useful to put
The problem is how to deal with them -- they have to be absolute URLs that are parseable by using the WHATWG URL constructor ( This could mean that, if We don't necessarily have to put |
|
I think that until node and all browsers have shipped it unflagged, webpack shouldn’t handle it. Users who want to use it early can use a custom babel transform for it - just like import() |
|
I jus
8000
t stumbled into |
|
For my use case Where fancy-button.js would do something like; Provided webpack would output this into a build folder keeping the component file structure intact (splitting chunks etc - still separate files, just the JS handled in webpack); I guess it would make sense for webpack to, in runtime, replace |
|
I'm working with the Polymer 3 preview and trying to use static get importPath() {
return import.meta.url
}The use case is to build the component which can detect whether it has been loaded from it's file (as it is performed by Polymer CLI when serving locally) or from a bundle (either Webpack or Rollup, etc). As a developer, I would expect the |
|
Since files can be loaded in the browser too, that doesn’t seem like a robust detection mechanism. |
|
I think a good first step would be to support parsing it at least. There are acorn plugins for it. |
|
The existing plugin is not usable as it is AGPL, and loading it would make webpack itself AGPL at runtime. |
|
It looks dual-licensed as that and Apache 2, so it’d be fine. |
|
It's dual-licensed with "and" so both licenses always apply. But this is getting into lawyer territory 🤔 |
|
\cc @adrianheine – there's more license concerns deviating from the MIT license of Acorn proper. |
|
Hi, if you want to use acorn-import-meta, you can choose under which license you want to use it. It is released under AGPLv3 and Apache2, so you can choose the one or the other :) |
|
It would be nice to achieve consensus on how to use Are there any existing efforts to create such a proposal? |
|
@Kovensky Is there any progress on this? As of now, Webpack is still failing to parse This makes |
|
@web-padawan Only stage 4 features are currently supported (except dynamic imports). We are waiting for |
|
hey, we just released a "temporary" loader - e.g. until webpack supports it out of the box that is. |
|
Any update on this one? Could at least update the webpack's parser to not crash? |
|
I think at this point basing decisions on stage version isn't the best way to go. |
|
The SystemJS community would also enjoy seeing Is there consensus on what |
|
I would be happy to look into what it would take to PR this -- parsing import.meta and replacing with whatever value is decided on. |
|
@joeldenning Okay, but would that variable 8000 need to be set manually by everyone who uses the library...? @evilebottnawi ok true but the problem is that 99% of this lib is not environment specific. There is ~2 sections (quite high up the call stack) that need to make fs calls. My current thinking is that at this point can split whether /// <reference lib="dom"/>
import { join, dirname } from "path";
if (typeof window !== "undefined") {
// @ts-ignore ts does not like during node compiliation `import.meta.url`
fetch(join(dirname(import.meta.url), "/bundle/x.txt"))
.then(x => x.text())
.then(x => console.log(x));
} else {
console.log(require("fs").readFileSync(join(__dirname, "/bundle/x.txt")).toString());
}Creating a branch of the library to not rely on fs calls is not possible. A solution would be to send down a function down that handles fs access and have separate web and node entry point where that function argument is different....? But I want to know why |
|
|
|
@kaleidawave If you're making a library, you generally won't compile it with Webpack. Your library will just use regular ES6 modules + dynamic The reason why It would help if you explained more what your goal is, so we can help you achieve that goal (rather than getting stuck on a particular implementation). |
Libraries are generally not compiled by webpack, and generally there is no good way to guarantee that runtime assets will be downloaded from the correct URL when publishing a webpack library. |
|
Interesting, looks like webpack isn't for this project.... @evilebottnawi I would counter that: Say I have console.log(import.meta.url)And its webpack'd to <script type="module" src="/src/index.js?hello='x'"></script>
<script type="module" src="/out/index.js?hello='x'"></script>Will log this: Unless I making the mistake that a webpack output is not to be used with non webpacked'd assets (as I need it to be) then it is not inline with the spec... |
|
@kaleidawave The point of Webpack is that all of your code is compiled with Webpack. It needs complete knowledge of all your code in order to compile the modules correctly. That's why the application is supposed to use Webpack, not libraries. It sounds like you're misunderstanding what Webpack does. Webpack is intended to take all of your ES6 modules and bundle them up into a single file (I'm leaving out some details about chunks, but that's the general idea). Webpack does not generate ES6 modules, Webpack generates raw ES5 code. So you don't use Webpack with If you instead want to generate ES6 modules, you should use something like Rollup instead. Like I said, it would help if you explained what your goal is, so we can help you to achieve it. |
We are working on it 😄 Hope it will be in near future |
|
We recently added this syntax: Using |
There's nothing unclear there. Read the spec. It's supposed to be the runtime base URL from which the module was obtained, i.e. loaded, for external script files; or the document's URL for modules defined inline in an HTML page. https://html.spec.whatwg.org/multipage/webappapis.html#hostgetimportmetaproperties Anything else is wrong. As I mentioned further back in this issue thread, the correct solution would've been to put Webpack-specific properties onto import.meta.url // -> "my/bundle/url.js#relative/path/to/file.js"
import.meta.webpack.bundle // -> "my/bundle/url.js"
import.meta.webpack.resource // -> "relative/path/to/file.js"This is completely in keeping with the spec and still has all necessary information to support every use-case, whether that is based on bundle URL or compile-time module path. |
|
@rjgotten You are confusing the bundle with modules. The bundle is not an ES6 module. In addition, that would create fragmentation within the ecosystem. Right now Webpack uses standard ES6 modules, standard ES6 dynamic With your proposal, now there would be a difference in behavior with So it would have to be the other way around: |
Incorrect. The spec literally states that
That difference is already there considering @kaleidawave showing that Webpack emits a |
Where is it in the specification? 😄 @rjgotten What is the your problem, please stop arguing and show your problem
Do you understand what it is bunder? Where should we store this? How? In runtime? Do you want a huge overhead? And why?
What? |
|
@rjgotten Wrong. It is a syntax error to use
That is because they are not compiling their entire code with Webpack (which is incorrect). When all of the code and assets are compiled with Webpack (as it should), then using
That may be a good idea, perhaps @sokra could explain the reasoning for using |
Yep, also we support |
|
The spec says
And thats exactly what we return. The module was obtained from the filesystem. That's where it's located. The bundle is a kind of transport format. Webpack also supports It also makes sense for Webpack tries it's best to map urls to there public counterpart if some exist. E.g. assets have a public URL and we use it. JS modules are bundled so they don't have a public counterpart. |
|
We can handle with |
|
Webpack team, The moment I add this line "const worker = new Worker(new URL('./myworker.js', import.meta.url));", I get this error on webpack-cli : "Critical dependency: Accessing import.meta directly is unsupported (only property access is supported)" However, if I use it const worker = new Worker('myworker.js') , it works fine bypassing webpack. The whole js fails to work when I try to use webworker with webpack 5 as per your documentation. Please fix this if its a bug. |
|
@echofriend Please provide reproducible example |
Hey, @sokra @ooflorent, @Kovensky @ljharb:
It looks like
import.metahas landed in Stage 3 and Babel has just landed it also. It looks like there is already an acorn plugin that allows for the syntax support.First piece is: Should we add this or wait?
Second piece is: Are there webpack specific things we should consider for this syntax. I feel like platforms (Electron, etc.) are going to start shoving a bunch of crap (which use to be globals) in these objects that we would automatically use to treat as Externals. Is there specific handlings that we need to be concerned here.
The text was updated successfully, but these errors were encountered: