Lately I was working on a vue3/vite + ts project and wanted to add eslint and prettier, but I'm getting confused what settings I should use in the eslint file(section "extends") and/or how to spell them. If I look at the official eslint vue homepage, they write the prettier stuff like the not commented out lines(picture below).But if I look at the official eslint-config-typescript page they write it like the commented out lines(picture below).
And if I google I find both examples in projects. So my question is:
Is there any difference between the writing?
Or do they do the same and it doesn't matter which one I take?
I don't know much about vue3/vite + ts, but I see here 2 moments:
Usage of #. It is likely to be related to webpack (I believe you use vue-cli). It usually means something like that: resolve: {alias: {'#': path.resolve('src')}}, So, # is just an alias for some path in your system, usually root/source folder for your project. You can find the exact path in webpack.config.js.
vue/prettier vs prettier/vue. Just location of the package. You either take prettier bundled with vue or a standalone prettier package that contains some custom/adopted version for vue. They are likely to be pretty much the same, check their package.json files for versions.
Related
i'm trying to implement rtl/ltr in my nuxt application.
this is my project structure
|--assets
|--scss
|--**/*.scss
|--bundle.scss
|--bundle-rtl.scss
so styles are compiled into the bundle and bundle-rtl normally.
the problem is this .. how can i switch between theses two scss files without changing them manually within my nuxt.config (automatically change the scss file when the language is changed).
among these files is a mixin file with many mixins related to rtl and ltr switching so i need to use them in each vue file that i have. which is why i can't just compile them to css (with gulp or webpack for example) and include them in head.
aside from all of this, is this the best way to implement ltr/rtl in nuxt or is there a better way?
In my opinion, you should write modern CSS that takes this into account rather than having a duplicate. This will have the benefit to also be usable by other languages.
Check this awesome article: https://css-tricks.com/building-multi-directional-layouts/
We're planning three similar vue projects. We already know that we will be able to reuse a lot of code (especially vue SFCs and simple js helper functions) in all of them and we're looking for a proper way to share the code between them.
Unfortunately the scope of the projects is rather different and a monorepo is not an option due to its limitations in read / write permission and visibility management. Therefore we're planning to handle the reusable parts as separate repos (and most likely private npm packages) which seems to be a straightforward approach. However, the question is: How can we create a convenient setup in which we are able to work on the shared components from within the scope of one of the parent projects?
Project A [project-repo-a]
project-specific stuff for A
private package A [package-repo-a] (conveniently editable from within project A)
private package B [package-repo-b] (conveniently editable from within project A)
Project B [project-repo-b]
project-specific stuff for B
private package B [package-repo-b] (conveniently editable from within project B)
private package C [package-repo-c] (conveniently editable from within project B)
In our PHP projects, there is a simple solution, we just require the reusable parts via composer with the prefer-source option which provides the full git repository which can be worked on right from within the parent application. However, as far as we understand there is no prefer-source thing in npm or yarn. So how can we achieve the desired setup? (Or are we overlooking a major downside of this setup in general?)
We already looked into / considered the following (without finding a suitable approach):
yarn / npm link: We understood, that we could use linking in general, but this seems to be a very inconvenient approach while constantly developing the shared components (and always having to publish them to reflect the latest changes).
yarn workspaces / lerna: Seem to be closest to what we want, however they seem to be (or are explicitly) designed for a monorepo approach. In the end they don't to provide a solution for actually getting the git source of a package (in a separate repo) into the parent project (since there is no --prefer-source thing) - do they?
using composer additionally: Just pulling the git sources down with composer and creating yarn workspaces from the composer vendor folder. However, this is obviously a hacky way and sounds quite error prone concerning the whole dependency management
using a yarn post-install script to pull down the git source of the required private packages, but as the composer way, this seems to be rather unpredictable in terms of module resolution, dependency management and so on.
using git submodules and yarn workspaces: Could be a solution. To be honest we're just completely unexperienced with git submodules and at a first glance it didn't look very intuitive. If there is no other way, we'll anyways consider to use this approach.
To be clear about this: We're not asking the taste question if one or the other of those approaches would be "best". We're feeling like none of them is the right one. The question is: Are we overlooking a technically clean and proven approach to our scenario, using npm, yarn or another package manager / dependency management solution?
Git X-Modules is a tool designed to do exactly what you were asking about. Here's a video that explains it. However, it's very new and therefore can't be really considered "proven" :-)
Yet, if you consider trying it, we would love to hear your feedback!
(As you may guess from the previous sentence, I am a part of the development team.)
you probably have already figured this out but have you looked into https://bit.dev/ ?
I'm currently considering it for a similar task to yours and it looks like it could do the job. Here's an article explaining how to use it https://blog.bitsrc.io/how-to-easily-share-vue-components-between-applications-1d30a1ad4e4d
I'm building a VUEJS dashboard and I want to generate multiple versions from this. I want to be able to load different logo images and titles. I'm building my app with vue-cli-service build but after an hour of googling I'm still in the dark how to configure the build process to make this possible. Is there somebody who can point me in the right direction?
I've read the docs about the target parameter, but I couldn't figure out how to make a different build. I just got the same in a different directory.
depending on your setup it might be a lot easier to use vue-js to change titles and images depending on the domain/path/env whatever.
if you MUST have a static build than you can find an answer here: How can I create two separate bundles with vue-cli 3?
Probably a little late to the game, but I expect what you want is to use modes and environment variables. It's documented very well here https://cli.vuejs.org/guide/mode-and-env.html.
Only variables that start with VUE_APP_ will be statically embedded into the client bundle with webpack.DefinePlugin. You can access them in your application code:
console.log(process.env.VUE_APP_SECRET)
During build, process.env.VUE_APP_SECRET will be replaced by the corresponding value. In the case of VUE_APP_SECRET=secret, it will be replaced by "secret"
You can set the paths/values of things you care about with env vars. You could also have each different build as a 'mode' and maintain env vars for each use case.
I'm trying to get my head around Webpack 4 for a medium-to-large scale (MVC) website.
For the solution, I want to use the following, base vendor scripts/styles:
jQuery vLatest minified version
Bootstrap, but only the grid, no javascript or anything else
The site consists on several templates different from each other. Some might have an image gallery where I want to use Owl Carousel vLatest and so on, so forth.
As I've understood, the vendor bundle should only contain the scripts/styles that is used across the entire site, so i.e., the Owl Carousel script/styles should not be a part of the vendor scripts since it's only used for one, maybe two specific templates.
I've installed jQuery and Bootstrap via npm so they're in the node_modules folder. Question is: how do I tell Webpack to use the minified version of jQuery in the vendor bundle? And how do I tell it to use only the grid component from Bootstrap? And what about the other third party scripts/styles, should they be included as their own entry?
My webpack.config.js entry file looks like this:
entry: {
'mysite.bundle.css': './scripts/webpack-entries/mysite.styles.js',
'mysite.bundle.js': glob.sync('./scripts/mysite/*.js'),
'vendor.bundle.js': [
'./node_modules/jquery/dist/jquery.min.js'
],
'vendor.bundle.css': [
'./node_modules/bootstrap/scss/bootstrap-grid.scss'
],
}
What feels weird about this is, that I could just aswell reference the jquery.min.js directly on my view and import bootstrap-grid.scss directly in my .scss files. Same could be said with the Owl carousel (and other vendor scripts)
Also, if I just do this: 'vendor.bundle.js': ['jquery'] the entire non-minified jQuery library is loaded rather than the minified version.
How exactly do you work with Webpack and NPM this way? :-)
Thanks in advance.
You can use { resolve } to configure aliases:
{
resolve: {
alias: {
'jquery': require.resolve('jquery/jquery.min.js')
}
}
}
However, I would caution first to focus on getting a viable build that's suitable for development and then enhance the configuration as needed to optimize for production. For example, during development you want to include all the sources with their entirety with good source maps. When you get to the point of publishing, use something like Environment Variables to introduce a flag that will enforce the necessary configuration.
No, it's not necessary to create entry points for particular vendor sources. This is reminiscent of the past practices. You should create individual entry points to logically split your large codebase into distinct bundles, like: the public web, the administrative application, the customer application, should you have the need to do so.
Also, don't spend too much time creating entrypoints to group vendor sources and such. Write your modules as you would, from the perspective of a developer, require from them what they depend on and then use webpack { optimize.minimizer }, other minification plugins and it's dependency graph heuristics to create necessary chunks using { optimize.splitChunks }.
Short answer is, and this has been true for webpack for a long time: do not change the way you write and organize sources to satisfy webpack. It's polished and sophisticated enough that it will accommodate to your style of authoring.
I am creating several mobile applications in react-native that share common components. I have difficulties handling the dependencies. Here is what I do, which is tedious, is there a better way?
A repository "common-modules" has shared components
Several repositories include the common one as a dependency like this:
Package.json
"dependencies": {
"common-components": "file:../common-components"
},
I use it like that in the different apps:
import XXX from 'common-components/src/...'
Now this is great because all other dependencies are in "common-components", but as soon as one of them has native code, I am forced to link the library again in each app.
For instance, if I use "react-native-image-picker", I have to install it again in each application and link it in XCode, edit build.gradle etc. etc.
It takes forever
Are my linked dependencies bundled twice?
I fear the day when I must change/upgrade one of them...
Is there a better way?
I've heard of projects that share code being managed in a monorepo. That may help managing shared code but won't solve the problem of linking native modules N times for N apps.
However, there is react-native link that should automate the process, and ease linking the native modules a lot. Note there is no need to re-link if you just upgrade a native dependency.
Alternatively, I think it should be possible to wrap multiple native modules into one. If you take a look at MainReactPackage.java in RN repo, it wraps several native modules. I imagine similar mechanism can be employed on iOS, with static libraries. Obviously, this means that it won't be easy to selectively include some modules and others not.
Like you said yourself it is easier to work with a duplicated codebase. To deal with that you can create your own package manager for your shared components. Make a script for each component which will add it's dependencies to package.json and configure gradle and XCode. Add a simple GUI to include your components with a single click.
This may seem like a lot of work upfront, but:
- you will keep full control
- once you have a script to install a component you will save time each time you use it on a new app
- in the case of updates you can create a script to handle that as well