# Web Worker javascript files **URL:** \ **Category:** rubyonrails-talk\ **Created:** [January 26, 2016, 3:05pm UTC](https://discuss.rubyonrails.org/t/web-worker-javascript-files/71599 "2016-01-26T15:05:16Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![Paul8](https://avatars.discourse-cdn.com/v4/letter/p/858c86/32.png) [@Paul8](https://discuss.rubyonrails.org/u/Paul8)\ **Post date:** [January 26, 2016, 3:05pm UTC](https://discuss.rubyonrails.org/t/web-worker-javascript-files/71599/1 "2016-01-26T15:05:16Z")
Using web workers in Rails seems a little awkward. I was wondering if anyone had a nice work flow. 1. Since they are loaded directly, they can’t be in the asset pipeline, so I created a folder under public: public/web\_workers/ Disadvantages: - The web worker code isn’t minimized. - The web worker code is not where all the other javascript files are, so it is a little bit “hidden” during development. - The web worker code doesn’t get the fingerprint, so I’ve had some issues with the browser caching the old code. Can anyone improve on this system? ---
**Author:** ![BenKoshy](https://sea2.discourse-cdn.com/rubyonrails/user_avatar/discuss.rubyonrails.org/benkoshy/32/3233_2.png) [@BenKoshy](https://discuss.rubyonrails.org/u/BenKoshy)\ **Post date:** [November 1, 2024, 10:02am UTC](https://discuss.rubyonrails.org/t/web-worker-javascript-files/71599/2 "2024-11-01T10:02:37Z")
Does this offer a solution? > > > This is a batch of several breaking changes. I'm planning to release them togeth…er in an upcoming release. TL;DR: \`new URL(...)\` and glob \`import()\`. In detail: > > \* Interpret and rewrite \`new URL(..., import.meta.url)\` expressions when bundling (\[#312\](https://github.com/evanw/esbuild/issues/312), \[#795\](https://github.com/evanw/esbuild/issues/795), \[#2470\](https://github.com/evanw/esbuild/pull/2470)) > > Some other bundlers have adopted a convention where the syntax \`new URL('./file.js', import.meta.url)\` causes \`file.js\` to be included in the current bundling operation as an additional entry point. The \`'./file.js'\` string is rewritten in the bundler's output to point to the resulting generated file for that entry point in the output directory (relative to the generated file containing the \`new URL(...)\` syntax). This is somewhat similar to how \`import('./file.js')\` works except that this reference just returns a \`URL\` object without importing the module. That lets you pass the URL of a module to other APIs such as \`new Worker(...)\` that take a script URL as input. > > Previously this pattern didn't work at all with esbuild, but it will now work in esbuild starting with this release. To use it you must ensure that bundling is enabled, that the output format is set to \`esm\`, and that code splitting is enabled (so you need to use \`--bundle --format=esm --splitting\`). In addition, the path must be a relative path (i.e. it must start with either \`./\` or \`../\`). Here's what using this feature looks like: > > \`\`\`ts > const url = new URL('./worker.ts', import.meta.url) > const worker = new Worker(url, { type: 'module' }) > > worker.onmessage = (event: MessageEvent) =\> { > console.log(event.data) > } > \`\`\` > > \* Handle import paths containing wildcards (\[#56\](https://github.com/evanw/esbuild/issues/56), \[#700\](https://github.com/evanw/esbuild/issues/700), \[#875\](https://github.com/evanw/esbuild/issues/875), \[#976\](https://github.com/evanw/esbuild/issues/976), \[#2221\](https://github.com/evanw/esbuild/issues/2221), \[#2515\](https://github.com/evanw/esbuild/issues/2515)) > > This release introduces wildcards in import paths in two places: > > \* \*\*Entry points\*\* > > You can now pass a string containing glob-style wildcards such as \`./src/\*.ts\` as an entry point and esbuild will search the file system for files that match the pattern. This can be used to easily pass esbuild all files with a certain extension on the command line in a cross-platform way. Previously you had to rely on the shell to perform glob expansion, but that is obviously shell-dependent and didn't work at all on Windows. Note that to use this feature on the command line you will have to quote the pattern so it's passed verbatim to esbuild without any expansion by the shell. Here's an example: > > \`\`\`sh > esbuild --minify "./src/\*.ts" --outdir=out > \`\`\` > > Specifically the \`\*\` character will match any character except for the \`/\` character, and the \`/\*\*/\` character sequence will match a path separator followed by zero or more path elements. Other wildcard operators found in glob patterns such as \`?\` and \`\[...\]\` are not supported. > > \* \*\*Run-time import paths\*\* > > Import paths that are evaluated at run-time can now be bundled in certain limited situations. The import path expression must be a form of string concatenation and must start with either \`./\` or \`../\`. Each non-string expression in the string concatenation chain becomes a wildcard. The \`\*\` wildcard is chosen unless the previous character is a \`/\`, in which case the \`/\*\*/\*\` character sequence is used. > > \`\`\`js > // These two forms are equivalent > const json1 = await import('./data/' + kind + '.json') > const json2 = await import(\`./data/${kind}.json\`) > \`\`\` > > This feature works with \`require(...)\`, \`import(...)\`, and \`new URL(..., import.meta.url)\` because these can all accept run-time expressions. It does not work with \`import\` and \`export\` statements because these cannot accept run-time expressions. It hasn’t been merged as of yet, but it looks promising.