-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
🐞 import.meta.url
transpile.
#2441
Comments
This was referenced Aug 5, 2022
4 tasks
mwu-tow
added a commit
to enso-org/enso
that referenced
this issue
Sep 21, 2022
This PR reverts two version bumps from #3712: * `yargs` needs to be downgraded, because a never version can trigger evanw/esbuild#2441 * `electron-builder` needs to be downgraded, because our workaround for electron-userland/electron-builder#6865 proved insufficient. As the upstream issues are resolved, we should bump these dependencies again.
@evanw is there a solution planned for this? This prevents us from bumping versions of several dependencies, including some critical ones :( |
Is it still not resolved? |
Why this need? |
2 tasks
craig-riecke
added a commit
to craig-riecke/graphiql
that referenced
this issue
Jan 6, 2024
Turns out I was quite naive about just excluding graphql-config. The extension worked under the Test Runner, but not when bundled and installed. This change actually does work, even when the plugin is bundled and installed separately. It uses the technique outlined in evanw/esbuild#2441
acao
added a commit
to graphql/graphiql
that referenced
this issue
Jan 6, 2024
* Update esbuild.js A possibly naive way to make vscode extension work after esbuild upgrade. * Update esbuild.js Turns out I was quite naive about just excluding graphql-config. The extension worked under the Test Runner, but not when bundled and installed. This change actually does work, even when the plugin is bundled and installed separately. It uses the technique outlined in evanw/esbuild#2441 * add changeset --------- Co-authored-by: Rikki Schulte <[email protected]>
We use this to dynamically determine path for import outside of javascript. esbuild options: ...
platform: "browser",
format: "esm",
bundle: true,
treeShaking: true,
splitting: true,
sourcemap: true,
... Consider this example: function inject_style(text: string) {
let newText = text;
const pathSearch = new RegExp(/(\\[START_RESOLVE_PATH\\])(?<RelativePath>.*)(\\[END_RESOLVE_PATH\\])/g);
const foundResources = text.matchAll(pathSearch);
for (const iterator of foundResources) {
const relPath = iterator["groups"].RelativePath;
const replaceRegexp = new RegExp(`(\\\\[START_RESOLVE_PATH\\\\])($\{relPath})(\\\\[END_RESOLVE_PATH\\\\])`);
const resolvedPath = import.meta.resolve(relPath);
newText = newText.replace(replaceRegexp, resolvedPath);
}
const style = window.document.createElement("style");
const node = window.document.createTextNode(newText);
style.appendChild(node);
window.document.head.appendChild(style);
} in a custom plugin: [custom esbuild plugin setup]....
onResolve({ filter: /^__style_helper__$/ }, () => {
return { path: "styleImporter.js", namespace: "style-helper" };
});
//if you pass he function as a string it will be correct, however if you pass the "function".toString() it will be "import_meta"
onLoad({ filter: /.*/, namespace: "style-helper" }, () => ({
contents: `export ${inject_style.toString().replace("import_meta","import.meta")}`,
})); |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When i use
esbuild
to transpileimport.meat.url
incjs
format, I always don't get the correct result.Reproduce
Expected
const import_meta = { + url: 'file:' + __filename }; import_meta.url;
The text was updated successfully, but these errors were encountered: