I am looking to apply different loaders to the same set of files so that two different outputs are produced. Specifically, I want to perform the following so that some larger images are created and also some smaller ones:
...
{
test: /\.(jpeg|jpg|png|gif)$/,
loader: 'my-loader',
options: {/* specific for generating a certain size of image */}
},
{
test: /\.(jpeg|jpg|png|gif)$/,
loader: 'my-loader',
options: {/* specific for generating a different size of image */}
}
...
I was looking at "multi-loader" in combination with "webpack-combine-loaders" as detailed at https://stackoverflow.com/a/53260488/1424591 but the Githib repo at https://github.com/webpack-contrib/multi-loader is marked as deprecated and the WebPack site at https://github.com/webpack-contrib/multi-loader states "dependencies: out of date" but I haven't been able to source why this is the case. Should I be using soemthing else?
Related
I'm using the rollup plugin strip to exclude the console.logs in the production built with following settings
plugins: [
strip({
include: ['**/*.(js|svelte)'],
labels: ['dev'],
functions: ['console.log'],
})
]
I now have the situation that I would like to keep one special log in production. So I created a function in a new file logInProduction.js
export function logInProduction(msg) {
console.log(msg)
throw new Error('PRODUCTION')
}
and added the file to the plugin options by adding this line
exclude: ['logInProduction.js'],
But when calling the function, the error is thrown, so the function was called, but the log before doesn't appear.
Is this because the .js ending is generally included before so the specific exclusion doen't have any effect? Is it possible to do this?
Or is there another maybe better way to keep one specific console.log?
Problem was, that the filename was missing the directory, so
exclude: ['src/utils/logInProduction.js'],
or
exclude: ['**/logInProduction.js'],
does work
I'm building a sveltekit project. One thing I've done is created a custom type of file which is converted to a *.svelte file upon building or running the development server. By default, sveltekit includes the rollup extension rollup-plugin-dynamic-import-variables which is trying to parse my custom file (who knows why?) and throwing an "unexpected token" error. I'm trying to configure that extension to ignore my custom files, but so far without success. Here is my attempted svelte.config.js file:
// #type {import('#sveltejs/kit').Config}
var config;
import adapter from '#sveltejs/adapter-static';
import dynamicImportVariables from 'rollup-plugin-dynamic-import-variables';
config = {
kit: {
// --- hydrate the <div id="svelte"> element in src/app.html
target: '#svelte',
adapter: adapter({
pages: 'build',
assets: 'build',
fallback: null
}),
vite: {
plugins: [
dynamicImportVariables({
warnOnError: true,
exclude: '**'
})
]
}
}
};
export default config;
To be honest about it, I don't use dynamic imports anywhere and therefore would accept as a solution the complete disabling of the extension. But anything that would get it to ignore my custom files would also work.
UPDATE: SvelteKit 1.0.0-beta now requires pages/endpoints to follow a specific naming pattern, so explicit file exclusion should no longer be needed.
SvelteKit specially handles files in the routes/ directory with the following filenames (note the leading + in each filename):
+page.svelte
+page.js
+page.server.js
+error.js
+layout.svelte
+layout.js
+layout.server.js
+server.js
All other files are ignored and can be colocated in the routes/ directory.
If, for some reason, you need to have a file that has a special name shown above, it's currently not possible to exclude that file from special processing.
Original outdated answer:
The rollup-plugin-dynamic-import-variables is actually included by Vite. To configure Vite's plugin, set the build.dynamicImportVarsOptions property:
// svelte.config.js
/** #type {import('#sveltejs/kit').Config} */
const config = {
kit: {
// hydrate the <div id="svelte"> element in src/app.html
target: "#svelte",
vite: {
build: {
dynamicImportVarsOptions: {
exclude: [/node_modules/, /\.starbucks$/],
},
},
},
},
}
export default config
But that's not going to fix the problem...
SvelteKit processes all files under src/routes/ so that they're automatically imported in the output application (in .svelte-kit/build/app.js), which will result in the same error.
Option 1: Private modules
You could exclude a src/routes/*.starbucks file by making it a private module, which has a leading underscore in the filename:
src/routes/_home.starbucks 👈
src/routes/_index.starbucks 👈
src/routes/index.svelte
Option 2: Move files outside src/routes
Alternatively, move those *.starbucks files outside of src/routes/ (e.g., into src/starbucks/ or src/lib/):
src/routes/index.svelte
src/starbucks/home.starbucks 👈
src/starbucks/index.starbucks 👈
src/lib/home.starbucks 👈
src/lib/index.starbucks 👈
I have a truststore file(a binary file) that I need to provide during helm upgrade. This file is different for each target env(dev,qa,staging or prod). So I can only provide this file at time of deployment. helm upgrade --set-file does not take a binary file. This seem to be the issue I found here: https://github.com/helm/helm/issues/3276. This truststore files are stored in Jenkins Credential store.
As the command itself is described below:
--set-file stringArray set values from respective files specified via the command line (can specify multiple or separate values with commas: key1=path1,key2=path2)
it is also important to know The Format and Limitations of
--set.
The error you see: Error: failed parsing --set-file data... means that the file you are trying to use does not meet the requirements. See the example below:
--set-file key=filepath is another variant of --set. It reads the
file and use its content as a value. An example use case of it is to
inject a multi-line text into values without dealing with indentation
in YAML. Say you want to create a brigade project with certain value
containing 5 lines JavaScript code, you might write a values.yaml
like:
defaultScript: |
const { events, Job } = require("brigadier")
function run(e, project) {
console.log("hello default script")
}
events.on("run", run)
Being embedded in a YAML, this makes it harder for you to use IDE
features and testing framework and so on that supports writing code.
Instead, you can use --set-file defaultScript=brigade.js with
brigade.js containing:
const { events, Job } = require("brigadier")
function run(e, project) {
console.log("hello default script")
}
events.on("run", run)
I hope it helps.
Is it possible to have one webpack dev server that's configured with multiple entry points (there are multiple pages on the site), each with a different configuration?
Specifically, I want one entry (the page's JS code) to be split into chunks, but another entry (JS localization bundle with translated messages) not to be chunked.
One possible complication, which you may ignore if you wish, is that I'm using Ruby-on-Rails webpacker, which automagically creates some of the webpack configuration for me.
You might be able to use a function for optimization.splitChunks.chunks to exclude your localization bundle by name as shown in the example in the Webpack docs: https://webpack.js.org/plugins/split-chunks-plugin/#splitchunkschunks
In Webpacker land, it might look like the following:
environment.splitChunks((config) => Object.assign({}, config, {
optimization: {
splitChunks: {
chunks(chunk) {
// exclude `my-excluded-chunk`
return chunk.name !== 'my-excluded-chunk';
}
}
}
}))
I have a problem implementing a cross domain custom build in Dojo.
The situation is as follows: i have a pretty large application, with a good number of localisation bundles, so basicly the directory structures is like
core\ (my module)
nls\
fr\
en\
....
When building my module the result is a big core.js/core.xd.js file, which, bien sur, does not contain the localisations. In the localisation nls directories (en/fr/etc) i find after the build each bundle builded/minified, and a bigger file for each language, core_fr.js/core_en.fs, which contains only Dojo/Dijit related strings.
so my build script is
layers: [
{
resourceName: "core",
name: "../core/trusted.js",
dependencies: [
"dojo.i18n",
//data
"dojox.data.JsonRestStore",
"dojox.data.XmlStore",
"dojox.rpc.Service",
"dojox.form.FileInput",
...
"core.controller.Fusebox"
],
prefixes: [
["dijit","../dijit"],
["dojox","../dojox"],
["core", "../core"]
]
In the core.controller.Fusebox class i try to load 1 nls
dojo["requireLocalization"]("core", "FuseboxContent");
here it will die, however with
availableFlatLocales is undefined
[Break on this error] var locales = availableFlatLocales.split(",");\r\n
My config in the html file is :
// version build
var djConfig = {
baseUrl: 'https://..../',
modulePaths: { 'core': 'core'},
useXDomain: true,
xdWaitSeconds: 10,
parseOnLoad: true,
afterOnLoad: true,
// debugAtAllCosts: true,
isDebug: true,
locale: "fr"
};
and then
<script type="text/javascript" src="http://xd.woopic.com/dojoroot/1.3.2-xd/dojo/dojo.xd.js.uncompressed.js"></script>
<script type="text/javascript" src="https://..../core/trusted.js.uncompressed.js"></script>
I used the uncompressed for debug, of course.
The problem is that, on runtime, Dojo tries to load my bundles and can not find them, and i would like to embed them in my layer file, so no extra loads will be required.
Can this be achieved? And while we're at it, are there any working sites/examples with cross domain localisations?
UPDATE: i continued my analysis and the problem seems to lay in the fact that i am dynamicaly loading nls, so the build parser can not find the requireLocalization() calls. Therefore the project nls file contains only dojo/dijit related content. However, i added a few bundle loads in a dummy file, and the content of core/nls is still ignored by the builder.
Thanks for any info, i am pretty much at the end of my searches, there isn't much on the net on this subject.
I had a similar issue a few days ago. First of all, you can get around the error by setting the available locales as the 4th parameter of the requireLocalization call.
e.g.
dojo.requireLocalization("core", "FuseboxContent", null, "en,fr");
though you should not have to do that.
Did you try including the localization as follows?
dojo.requireLocalization("core", "FuseboxContent"); // and not dojo["require..."]