\n- \n
Fix Symbol.metadata on classes without a class decorator\n(#3781)
\nThis release fixes a bug with esbuild's support for the decorator\nmetadata proposal. Previously esbuild only added the\nSymbol.metadata property to decorated classes if there was\na decorator on the class element itself. However, the proposal says that\nthe Symbol.metadata property should be present on all\nclasses that have any decorators at all, not just those with a decorator\non the class element itself.
\n \n- \n
Allow unknown import attributes to be used with the copy\nloader (#3792)
\nImport attributes (the with keyword on\nimport statements) are allowed to alter how that path is\nloaded. For example, esbuild cannot assume that it knows how to load\n./bagel.js as type bagel:
\n// This is an error with "--bundle"\nwithout also using "--external:./bagel.js"\nimport tasty from "./bagel.js" with { type: "bagel"\n}\n
\nBecause of that, bundling this code with esbuild is an error unless\nthe file ./bagel.js is external to the bundle (such as with\n--bundle --external:./bagel.js).
\nHowever, there is an additional case where it's ok for esbuild to\nallow this: if the file is loaded using the copy loader.\nThat's because the copy loader behaves similarly to\n--external in that the file is left external to the bundle.\nThe difference is that the copy loader copies the file into\nthe output folder and rewrites the import path while\n--external doesn't. That means the following will now work\nwith the copy loader (such as with --bundle\n--loader:.bagel=copy):
\n// This is no longer an error with\n"--bundle" and "--loader:.bagel=copy"\nimport tasty from "./tasty.bagel" with { type:\n"bagel" }\n
\n \n- \n
Support import attributes with glob-style imports (#3797)
\nThis release adds support for import attributes (the\nwith option) to glob-style imports (dynamic imports with\ncertain string literal patterns as paths). These imports previously\ndidn't support import attributes due to an oversight. So code like this\nwill now work correctly:
\nasync function loadLocale(locale: string): Locale {\nconst data = await import(`./locales/${locale}.data`, { with: { type:\n'json' } })\n return unpackLocale(locale, data)\n}\n
\nPreviously this didn't work even though esbuild normally supports\nforcing the JSON loader using an import attribute. Attempting to do this\nused to result in the following error:
\n✘ [ERROR] No loader is configured for ".data"\nfiles: locales/en-US.data\nexample.ts:2:28:\n2 │ const data = await import(`./locales/${locale}.data`, { with: {\ntype: 'json' } })\n ╵ ~~~~~~~~~~~~~~~~~~~~~~~~~~\n
\n
\nIn addition, this change means plugins can now access the contents of\nwith for glob-style imports.
\n \n- \n
Support ${configDir} in tsconfig.json files\n(#3782)
\nThis adds support for a new feature from the upcoming TypeScript 5.5\nrelease. The character sequence ${configDir} is now\nrespected at the start of baseUrl and paths\nvalues, which are used by esbuild during bundling to correctly map\nimport paths to file system paths. This feature lets base\ntsconfig.json files specified via extends\nrefer to the directory of the top-level tsconfig.json file.\nHere is an example:
\n \n
\n\n