@rollup/plugin-url does not use the asset mechanism
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 42/100
- Tipo de issue
- Error
- Claridad
- Bastante claro
- Estado de actividad
- Estancado
- Stack tecnológico
- javascript
- Área
- build-system, tooling
Línea de trabajo
Start by locating the @rollup/plugin-url implementation and tracing its current filesystem copying, asset URL generation, and destDir/publicPath handling. Compare that behavior with Rollup's emitFile, asset output, and resolveFileUrl APIs; done means the plugin uses the asset mechanism while documenting or testing the resulting breaking behavior. No file or test path is named in the issue.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
- Rollup Plugin Name: @rollup/plugin-url
- Rollup Plugin Version: 8.0.2
Expected Behavior / Situation
The plugin mechanism offers an emitFile function meant for copying asset files to the output directory. By only referencing the files through their reference ID, the build system is able to keep track of dependencies. The list of produced asset files is also reflected in the output.
Actual Behavior / Situation
@rollup/plugin-url uses regular file system operations to manually copy the files over. This is bad because among other things, it means there is no method to retrieve a list of copied asset files. As this information seems to be part of the intended output of a Rollup build, I consider this a bug (but apparently I'm wrong).
Modification Proposal
Use the correct APIs. Especially since this is an official plugin, it should absolutely set a good example and use the officially provided API for file management. I'm even willing to provide a PR for it.
While this is relatively straightforward to fix, it has some implications on the API of this plugin. For example, the emission of assets can't be turned off by the plugin anymore, only in the output settings. I believe this is intended, but it is a breaking change.
Likewise the destDir parameter won't make sense anymore, since that is also determined by the build output (and that is definitely correct). This means that if the plugin was previously used for unintended purposes of dropping files outside of the output directory, that "functionality" would be broken.
The publicPath behavior may need to be rethought in light of the default file import URL handling of Rollup. My understanding is that import.meta.url is supposed to fill that role, which would again make the parameter obsolete. For now I've opted to just replicate the current output exactly by overriding resolveFileUrl.
- Lenguaje dominante
- JavaScript
- Estrellas
- 3.8k
- Forks
- 635
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de rollup/plugins
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
-
Dificultad 4/5 3-5 días Aptitud para principiantes 52/100
-
Dificultad 3/5 1-2 días Aptitud para principiantes 48/100
-
Dificultad 4/5 3-5 días Aptitud para principiantes 48/100
-
Support js-yaml v5 Abierto
Dificultad 4/5 3-5 días Aptitud para principiantes 45/100
Todos los issues de rollup/plugins
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
HarperFast/skills#96 ·
-
[Block] Latest Posts [Type] Bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
-
Daemon passes --experimental-wasm-jspi unconditionally on Node >= 24; Node 26 rejects the flag Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Automattic/studio#4908 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 86/100
sugarlabs/musicblocks#8847 ·