Vue-CLI and Visual Studio Code formatting conflicts - vue.js

I generated a Vue.js project using this tutorial: https://www.vuemastery.com/courses/real-world-vue-js/vue-cli/
And then I proceeded to change Visual Studio Code settings and project configuration as described here: https://www.vuemastery.com/courses/real-world-vue-js/optimizing-your-editor
Unfortunately, this caused the Vue-CLI and Visual Studio Code to have different formatting settings. Whenever I save a file in VS Code, it gets formatted (which is fine). But when I run a command in Vue-CLI, all the files get reformatted by different rules. This means that almost all the files get modified even if the change is irrelevant to what I'm doing. This is driving me crazy.
How can I get these tools "in sync" so that they don't apply different formatting rules? Which configuration files are relevant for this?
Or would it be possible do disable the formatting in Vue-CLI completely?
UPDATE:
Recently I noticed that VS Code is messing up the formatting by itself. Even without using Vue-CLI. When I make changes to a .vue file and save them, VS Code adds trailing commas after last elements in javascript maps. When I make a couple of additional changes, the commas stay there. But then with another change, it suddenly removes them all. This behavior seems completely random.

I created a file called prettierrc.js in the root directory with the following content:
module.exports = {
trailingComma: "all",
arrowParens: "always",
};

Related

Comma doesn't seem to find "Legacy extensions" for some modules

I’m trying to figure out how to use the feature for automatically update legacy extensions with the Comma IDE. It either behaves inconsistently or I'm not understanding something clearly. I used Comma as recently as last week to generate a patch for the XDG::BaseDirectory module for updating the legacy extensions. It worked fine.
Yesterday, I downloaded the spit module.
I opened the module in a new project in Comma CP, v2022.10.
With the project open, I click Tools -> Update file extensions.
I get a “No legacy extensions detected” message.
However, the module is full of files with .pm6 and .t extensions.
I’m not sure what it is about the “spit” module that prevents it from working. I also tried it with another module, Router::Boost, and ran into the same problem. I also tried with the latest version of Comma CT and ran into the same problem. Finally, I tried fiddling with some properties in the META6.json file to get it working but had no luck with that, either.
Anyone know how I can get this feature working again?
OK, this has been solved.
When opening a downloaded distro for the first time, DO NOT do "File -> New -> Project".
Instead, use "File -> New -> Project from existing source."

Is theme validation required for Bigcommerce's Stencil theme development

When using "stencil bundle" is it required to have validated code? It seems it wont export unless the errors are fixed.
It is, yes. But as a temporary solution while in development you can always add some entries to the .eslintignore file (as specified here) present in your root folder. You will have some already there for reference. That will be useful for plugins and modules not written by you that ESLint might not let pass. ;)

Sylius Stylesheet Not Reloading

So here's a question. I'm new to Sylius, and am working on some simple CSS updates. I have a local copy of Sylius running with the built-in webserver: server:run. I also have a development server on Digital Ocean, which runs an (almost) identical copy of Sylius, aside from the configs of course.
Something strange is happening with my CSS update, however. I made a change to .navbar-brand within web/assets/compiled/backend_backend_4.css.
This change showed up immediately on my local. On the development server, however, when pulling down the change (git), and verifying that it now exists in that file, the change doesn't seem to propegate. It's effects aren't shown, inspecting the stylesheet doesn't show them, and furthermore viewing the css file sourcecode directly in the browser does not show the change. But on the filesystem it's definitely there.
I've tried clearing the cache, to no avail.
I also checked the assetic value in both config_dev.yml files, and verified they are both set to use_controller: true
Even still, I tried dumping assetic, to no avail.
So I'm wondering what's going on. Additionally, I realize that I probably shouldn't edit CSS files within a folder called 'compiled'. I'm sure there's a way to do that using a compiler, but I'm not yet familiar with the process and am just making minor changes and learning about caching so far.
Yes you are right you shouldn't be editing the compiled files.
You should edit the source files, then run gulp
or on my system i have to explicitly run npm run gulp
I've documented the solution that worked for me here. It didn't involve Gulp at all, but instead uses Assetic:
Assets need to be installed as hard copies first (I'm not quite sure
what this does exactly, but it seems like an important step because
it copies a lot of assets to places. Documentation was unhelpful but
it was suggested on Stack Overflow somewhere.):
app/console assets:install web
Assets should be edited in web/bundles/[bundle-here]/css or js. This
is frequently within syliusweb if it has to do with page styles /
layouts.
Hint: These assets are referred to in files such as
src/Sylius/Bundle/Resources/views/Backend/layout.html.twig (see the
opening:
(% stylesheets
tag, or search universally for this tag).
Within this tag, you'll see that stylesheets have an output to the compiled folder, but also list the
bundles where they pull their original css from. You should edit one of the source css files, if you'd like your changes to end up in the destination css.
After editing assets, dump assetic:
php app/console assetic:dump
Note - it is also possible to set an assetic watcher on these assets
(google to find out how, think it's a -w flag somewhere), but this is
said to only work in development mode, as it should.
After dumping assetic, the assets from the source bundles compile into their assets/compiled versions, usually combining multiple stylesheets. You should now see your asset refresh!

Webpack sometimes fails to detect changes saved with Intellij Idea

I'm developing a JavaScript/React application in Intellij Idea and I'm using webpack-dev-server to incrementally build my files. That means that the dev server is watching the files and if a file gets changes, webpack rebuilds it. Pretty standard scenario.
Unfortunately, webpack sometimes decides to ignore certain files. I can change them all I want but webpack does nothing. I have not been able to determine any pattern on which files get ignored. It's arbitrary. Sometimes I just create a new file and webpack ignores it.
What is interesting though is that it only happens when I perform the save using Intellij Idea. If I open the file in another editor (for example vim) and save it, the file gets correctly rebuilt. Actually, simple touch file.js is enough to trigger rebuilding.
I guess there is something wrong in how Intellij Idea saves files. Any ideas?
This is due to an IDE feature known as "safe write". When enabled, the IDE will write the changes to a temporary file over the real one. This means webpack's file watching mechanism cannot pick up the changes. Disable this feature to fix the problem. Reference.
For me this did not work, I'm posting this in case anyone has the same scenario. After each save, webpack watch script builds the new bundles and I'm reloading all files from disk (CTRL + ALT + Y). Only after that the changes are visible.
There is an open issue "Background" changes by external tool not being picked up until VFS refresh happens regarding this behavior: file is saved but one has to reload all from disk in order to see the changes (for example in the browser).

UglifyJS file watcher in IntelliJ minifies already minified files during build

I have an UglifyJS file watcher set up in IntelliJ IDEA, and it works great while I'm editing -- I modify the source js, the minified version gets created next to it automatically.
However, when I run an Ant build, and it copies the minified versions into the build working dir, the watcher "helpfully" creates doubly minified versions of them (*.min.min.js) in the build working dir, not ok.
I've set the Scope of the watcher to the 'src' module, but apparently that doesn't do what you'd think it would, because the doubles get created when Ant copies files into the 'build' module. Happens when I use IDEA to manually copy a single file from src to build too.
I don't see how to set this up to include *.js but exclude *.min.js, which is really the right thing. (Seems so sensible that Uglify should have it built in, but far as I can see it doesn't.)
Other than getting rid of the watcher and scripting the build do the minification, or copying only the original js versions and letting the watcher (re)create the minified ones, what's the best way to go here?
Got this working, thanks to a helpful commenter on the IDEA forum. The key is setting up a custom Scope, which I tried to do before but failed.
Pattern I ended up with was this, for anyone with similar needs:
file[src]:*.js&&!file:*min.js*
Making the 'src' module current then opening the dlg and selecting it from the dropdown in the main watcher config window apparently doesn't actually filter by that module. Clicking the ... btn, then choosing it from the dlg that opens does, plus I added an explicit filename pattern to exclude already minified files too.
Works great now, far as I've tested (both a minimal Ant test and manually copying a file to 'build' in IDEA).
This is an old question, and perhaps the Watchers didn't have this functionality at the time.
Using JetBrains 'macro' codes makes the 'min.min.min.js' problem go away.
$FileNameWithoutAllExtensions$.js -m --source-map -o $ContentRoot$\prod\js\$FileNameWithoutAllExtensions$.min.js
I always set 'Scope' to 'Current File', too; why run uglify on files that haven't been altered? (I'm assuming that any 3rd party JS libraries are already minified).