I have some pdf files on my website, lets call them a,b,c,d (all ending with .pdf).
These files don't sit all under the same path (there is a total of 3 different directories), for example we have
https://example.com/first_dir/a.pdf
https://example.com/first_dir/b.pdf
https://example.com/second_dir/c.pdf
https://example.com/third_dir/d.pdf
I have the following alias dictionary:
name_conversions = {
'first_name' : 'first_dir/a.pdf'
'other_name' : 'first_dir/b.pdf'
'another_name' : 'second_dir/c.pdf'
'yet_another_name' : 'third_dir/d.pdf'
}
and I want to create redirections according to this dictionary, so that when we access https://example.com/first_name we get redirected to https://example.com/first_dir/a.pdf, and same goes for the other entries.
How can this be done in webpack? If this can't be done in webpack what are the alternatives, that hopefully don't require me making a lot of new files, one per pdf, and don't require creating copies of these pdfs.
I've seen people use webpack proxy for this, but this is not for production from what I understood, and only for development.
Update: I found a plugin for doing redirects, but I can seem to find how to use it.
I found out I can use the package redirect-webpack-plugin.
All I need to do is the following:
module.exports = {
...
plugins: [
new RedirectWebpackPlugin({
redirects: name_conversions
})
...
]
...
}
Related
I have been trying to use publicRuntimeConfig / privateRuntimeConfig
On nuxt 2.4.1, I have defined my runtime config as follows on nuxt.config.js
publicRuntimeConfig: {
DATA_API_HOST_URL: process.env.VUE_APP_DATA_API_HOST_URL,
},
privateRuntimeConfig: {
AUTH_APP_CLIENT_SECRET: process.env.VUE_APP_AUTH_APP_CLIENT_SECRET,
},
and calling it as follows on my login.vue
asyncData( ctx ) {
console.log(ctx.$config.DATA_API_HOST_URL)
//some activity
}
The keys are showing up on $config inside asyncData. I debugged on chrome dev tools. But value is not read from process.env.VUE_APP_DATA_API_HOST_URL. The value is showing up as undefined. However, process.env.VUE_APP_DATA_API_HOST_URL is showing the value OK. The whole point is to move away from process.env.
this.$config.DATA_API_HOST_URL also does not access the values.
'${DATA_API_HOST_URL}' is shown in examples but I believe it is only for explicit param declarations at asyncData like asyncData( { $config : {DATA_API_HOST_URL}).
When I pass values as it is using DATA_API_HOST_URL: process.env.VUE_APP_DATA_API_HOST_URL || 'https://test.api.com', it seems to copy the value fine using ctx.$config.DATA_API_HOST_URL!
Looking to me like copying process.env to *RuntimeConfig has a problem!
What is the recommended way of importing and using runtime configurations?
As per documentation in the Nuxt blog post you marked, the feature your are trying to use is released in 2.13 (you´re using 2.4 if i not misunderstood). That could be the reason behind the behaviour you're seeing.
I'd recommend update your project dependencies or trying another approach.
I think you should use Docker to set dynamic runtime config like link below:
https://dev.to/frontendfoxes/dockerise-your-nuxt-ssr-app-like-a-boss-a-true-vue-vixens-story-4mm6
I use rollup with rollup-plugin-scss plugin in the project to bundle css. Is it possible to generate both .css and .min.css using this plugin or some other plugins?
plugins: [
scss({
output: path.resolve(__dirname, 'projects/project_name/main.css'),
})
]
I tried to add outputStyle: "compressed" but this make only compressed version, not both.
It is not possible out of the box but you hook into the output option that also take a function as option and write both files manually (including a compression step). In the sample code below I used clean-css but there are plenty of other packages available.
scss({
output: function (styles, styleNodes) {
fs.writeFileSync('bundle.css', styles)
const compressed = new CleanCss().minify(styles).styles;
fs.writeFileSync('bundle.min.css', compressed)
}
})
Note that this setup does not have any logging or filesizes or anything as you get it from the regular plugin, but this is something that can be added fairly easily into the function.
I am playing with Gulp.js & npm recently, it's great. However, I do not really get the idea of npm as a package manager for packages which will get pushed for dist.
Let's go with an example.
I want to download the latest jquery, bootstrap and font-awesome so I can include them into my project. I can simply download them from their websites and get the files to include. Another option seems to be a packet manager, i.e. NPM.
However, my node_modules directory is huge due to other packages such as gulp, and it's not nested at all. What would be the easiest way to move selected packages to another dir - for example src/vendors/
I was trying to achieve that by gulp task simply copying specified files from node_modules and moving them to a specified dir, nonetheless in the long run it's almost the same as manually copying files since I have to specify not only the input directory, but also the output directory for each single package.
My current solution:
gulp.task('vendors', function() {
var jquery = gulp.src(vendors.src.jquery)
.pipe(gulp.dest(vendors.dist.jquery));
var bootstrap = gulp.src(vendors.src.bootstrap)
.pipe(gulp.dest(vendors.dist.bootstrap));
return merge(jquery, bootstrap);
});
vendors = {
src: {
jquery: 'node_modules/jquery/dist/**/*',
bootstrap: 'node_modules/bootstrap/dist/**/*'
},
dist: {
jquery: 'src/resources/vendors/jquery',
bootstrap: 'src/resources/vendors/bootstrap'
}
}
Is there an option to do it faster and/or better?
There's no need to explicitly specify the source and destination directory for each vendor library.
Remember, gulp is just JavaScript. That means you can use loops, arrays and whatever else JavaScript has to offer.
In your case you can simply maintain a list of vendor folder names, iterate over that list and construct a stream for each folder. Then use merge-stream to merge the streams:
var gulp = require('gulp');
var merge = require('merge-stream');
var vendors = ['jquery/dist', 'bootstrap/dist'];
gulp.task('vendors', function() {
return merge(vendors.map(function(vendor) {
return gulp.src('node_modules/' + vendor + '/**/*')
.pipe(gulp.dest('src/resources/vendors/' + vendor.replace(/\/.*/, '')));
}));
});
The only tricky part in the above is correctly figuring out the destination directory. We want everything in node_modules/jquery/dist to end up in src/resources/vendors/jquery and not in src/resources/vendors/jquery/dist, so we have to strip away everything after the first / using a regex.
Now when you install a new library, you can just add it to the vendors array and run the task again.
I'm having a hard time locating specific style rules in less, what is the ideal workflow for quickly finding and modifying the rules and structure of the default less files?
The Magento Documentation is pretty helpful here - http://devdocs.magento.com/guides/v2.0/frontend-dev-guide/css-topics/css_debug.html
Source maps are probably the best LESS debugging tool.
For client side compilation configure options in lib/web/less/config.less.js.
The option you want is:
dumpLineNumbers
Type: String Options: ''| 'comments'|'mediaquery'|'all' Default: ''
When set, this adds source line information to the output css file. This helps you debug where a particular rule came from.
- http://lesscss.org/usage/#using-less-in-the-browser
If you want server side compilation, you can use grunt which is built in to Magento 2. Checkout the dev/tools/grunt/configs/less.js file, it shows
var lessOptions = {
options: {
sourceMap: true,
strictImports: false,
sourceMapRootpath: '/',
dumpLineNumbers: false, // use 'comments' instead false to output
...
The documentation will step you through using Grunt, or setting up client side less compilation.
I want to use puppet to manage some servers. Even after reading dozens of documentation pages, it is not clear to me how to use modules and how to use them with hiera. As first experiment I wanted a user "admin" to be created on one node and found this module -> https://github.com/camptocamp/puppet-accounts
My /etc/puppet/hiera.yaml looks as simple as this
---
:backends:
- yaml
:hierarchy:
- node/%{::fqdn}
- common
:yaml:
:datadir: /etc/puppet/hieradata
My /etc/puppet/hieradata/node/node1.example.com.yaml contains this
---
accounts::users:
admin:
uid: 1010
comment: admin
accounts::ssh_keys:
admin:
comment: ad
type: ssh-rsa
public: AAAAAAAAAAAAAA
This worked after I put this in my /etc/puppet/manifests/site.pp
hiera_include('classes')
class
{
'accounts':
ssh_keys => hiera_hash('accounts::ssh_keys', {}),
users => hiera_hash('accounts::users', {}),
usergroups => hiera_hash('accounts::usergroups', {}),
}
accounts::account
{
'admin':
}
Is this good practice? To me it feels wrong to put that stuff into site.pp since it gets messed up when I later use more modules. But where else to put it? I also don't understand how this separates data from logic, since I have data in both, node1.example.com.yaml and site.pp (admin). Some help would be great..
To understand what hiera is, you should think simply that Hiera is a DATABASE for puppet, a database of Variables/values and nothing more.
For a beginner I would suggest to focus on other parts of the system, like how to create modules! and how to manage your needs (without complexity) and then slowly build the "smart" recipes or the reusable ones...
Your puppet will first sick for a file called sites.pp (usually is on your main $confdir (puppet.conf variable. I am not going to mention environments it is for later.)
e path is /etc/puppet inside that directory, you have a directory manifests. There is the place for your sites.pp
usually a sites.pp structure is:
node default {
include *module*
include *module2*
}
node /server\.fqdn\.local/ {
include *module2*
include *module3*
}
this means that you have a default Node (if the node name doesn't fit any other node, will use the default, otherwise it will use the regex matching of the node FQDN in this case server.fqdn.local.
The modules (module, module2 and module3) are stored inside the $modulespath set on your puppet.conf. In our case i will use the: /etc/puppet/modules
the tree will look like:
/etc/puppet/modules/
/etc/puppet/modules/module/
/etc/puppet/modules/module/manifests/
/etc/puppet/modules/module/manifests/init.pp
/etc/puppet/modules/module2/
/etc/puppet/modules/module2/manifests/
/etc/puppet/modules/module2/manifests/init.pp
/etc/puppet/modules/module3/
/etc/puppet/modules/module3/manifests/
/etc/puppet/modules/module3/manifests/init.pp
About
classes: https://docs.puppetlabs.com/puppet/latest/reference/lang_classes.html
generally what i explained but from puppet labs: https://docs.puppetlabs.com/puppet/latest/reference/dirs_manifest.html
Please note that the example from the README
class { 'accounts':
ssh_keys => hiera_hash('accounts::ssh_keys', {}),
users => hiera_hash('accounts::users', {}),
usergroups => hiera_hash('accounts::usergroups', {}),
}
is catering to users of Puppet versions before 3.x which had no automatic parameter lookup. With a recent version, you should just use this manifest:
include accounts
Since the Hiera keys have appropriate names, Puppet will look them up implicitly.
This whole thing still makes no sense to me. Since I have to put
accounts::account
{
'admin':
}
in a manifest file to create that user, what for is hiera useful in this case? It doesn't separate data from logic. I have data in both, the .yaml file (ssh keys, other account data) and in a manifest file (the snippet above). By using hiera I expect to be able to create that user inside /etc/puppet/hieradata/node/node1.example.com.yaml but this is not the case. What is the right way to do this? What for is the example hiera file of this module useful? Wouldn't it be easier create an account the old style way in site.pp?