I'm using Laravel mix in my project. I need to alter the app.css in the public folder, whenever i comment or delete styles and run npm run dev the styles come back. I need them gone. How do I permanently stop this?
The files in public generated by npm run [production|dev] are compiled versions of the application's source files. These files should be treated as immutable: they are written once during the compilation process and never to be written to again. Any changes you need to make to the output should be done in the compilation process, whether that's by modifying the source files or by adjusting the way that the compilation process works. Every time you run npm run dev it replaces the old files with the new.
You can find the source files for your application in resources/assets. If you're not sure how to make a specific change please create a new question outlining the problem you're having, e.g: "I want to remove this style from my app.scss but I don't know how".
Related
My Eclipse project uses Sass. When running in debug mode, sass:watch (configured per this article) correctly polls for changes to *.scss files, compiles them into CSS and places them in the target directory. However, these changes are not reflected on the page, and inspecting the page using Chrome developer tools shows the new CSS is not picked up.
Using another (CSS-only) project works as expected: any change to CSS is copied to target directory, and a refresh of the page reflects the proper change.
I ran across a similar issue someone had using LESS. Unlike that situation, though, even changing the target CSS directly, the change is not reflected in the browser.
I can't be the only person debugging Sass/CSS in Eclipse, but I can't find any info on this problem.
Any ideas on how to fix this?
EDIT: SCSS is being compiled to CSS and copied to the target build directory, but not into the Tomcat deployment where the code is running. As I've said, this is not an issue with CSS-based projects, only with this where it's a compiled file.
Solved the problem...
An entry needed to be added to Eclipse’s Web Deployment Assembly so that Eclipse would see this dynamically-generated folder and associate it with the project.
The files were being generated to the local_repo/target/branch_name directory, where branch_name was dynamic, and dependent upon what branch you were working on; this made it impossible to create a static entry in Eclipse WDA for us.
Our solution was to have Maven (1) create a sass-generated/css directory under local_repo/target, and (2) copy the css over into the branch_name/static directory where it belongs.
Now, when debugging locally and running Sass Watch, changes to *.scss files are detected, compiled to css, and deployed to the sass-generated/css directory. Since this dir is associated with the project in Eclipse WDA, Eclipse sees the change and deploys it to Tomcat as expected!
I'm developing a progressive web app using Vue.js.
While I'm developing I use the command npm run dev to start the local server which serves the files on http://localhost:8080/. When I want to build for production I use npm run build prod which generates the output files in project\dist. I then take those files and copy them onto an ISS which is configured to work with single-page applications. All good so far.
I noticed some differences in the way the app looks (css) between the dev and prod build. First I thought this might be because of a client side cache, but after several tries to clean the cache and no-cache loading I'm sure that caching is not the issue here. The output really is different.
To be honest, I'm not sure if there is anything else different besides a few minor css parts. I was thinking what might be the issue, one of the things I noticed that could be the cause is that I use single file components in vue with scoped css (*.scoped.vue.css file names). I guess there could be an issue combining the different files into a single one?
It might be noted that I'm quite a newby when it comes to npm, webpack and all the other involved technologies. If you want to take a look at the configuration, you can find my current working branch build configurations here.
Any idea what the issue might be?
I encountered the same problem when using single file components. The issue indeed seems to be that when you run npm run build it will generate one single css file without the guarantee that the styling will be applied in the same order, causing some property values to be ignored. I 'fixed' it by adding !important to the properties that weren't matching up in the final build. There's probably a better way to handle this, but I must admit I too am quite a newby.
The order of how styles are applied while npm run build matters, and is to my knowledge out of (y)our control. To get rid of conflicts, when using Vue.js, you may want to scope your styles.
In every *.vue file within your project, replace
<style>
...
</style>
With
<style scoped>
...
</style>
I have an application that was created from create_react_app then ejected, with no modifications.
Everything works as expected when running the dev version.
Unfortunately when I do npm run build and run this via serve -s build my styles are not working.
The .css files are being found and compiled into a single minified version. But the problem is that the markup that is generated is having the class name prefixes changed to 'T-' instead of the prefix in the compiled .css file. (i.e) MyApp-header is getting changed to T-header, but in the minified css file, it still refers to MyApp-header.
prefix changed to T-
Any help would be appreciated.
This issue turned out to be caused by some nuance of using this...
#SuitCssify.decorator
I was evaluating this library for potential use in a project, and didn't discover this issue until trying to produce an actual production build.
I've since abandoned this approach and changed my configuration to use "CSS Modules" which are working out great. I would provide a link, but my reputation only allows me one link per post. ;(
my 'webpack.config.[dev & prod].js' changes to enable css modules
I'd like to do the inverse of this question/answer:
How to include TypeScript files when publishing?
The thing is that I'm trying to publish an ASP.NET MVC 5 Project. Unfortunately the dreaded Visual Studio and the hungry Jack Typescript interpreter ignores any tsconfig.json file and decides to go deep down and look for any .ts file that is not accompanied by a .js. I have lots of npm packages nested down and some of them have uncompiled typescript files.
Funny thing is, that they are not included in the project (not even an exclamation mark). (I even checked for the .csproj and no files were found).
Is this a bug? How can I prevent this from happening? Using VS 2015.2 (Update 2).
I had a very similar issue. Publish kept failing because it couldn't find foo.js as it wasn't in the same directory as my ts/tsconfig files, even though outDir was set to another location. I don't know if it is a bug or not but I couldn't figure it out using the tsconfig. Instead, I was able to get things working by using the inbuilt TypeScript Build settings instead.
First, I deleted all tsconfig files from my project (I made sure I kept a backup just in case). The TypeScript Build was originally greyed out because I had the tsconfig files in my project.
Next, I created a new folder directly under Scripts to save the js files into.
I then went to Project Properties and selected the TypeScript Build tab. Under Output, I checked the Redirect JavaScript output to directory and browsed to the newly created folder. I repeated this for all build configurations.
Finally, I included the new folder in my project and then built. Folders and files which aren't included in the project can be seen as a ghost icon in the Solution Explorer if you have Show All Files icon selected. I think that if you have multiple TypeScript projects with their own tsconfigs, the file structures are replicated under the chosen output directory but I haven't tested it in many cases so I'm not certain.
Obviously I had to redirect my script bundles to the newly created js structure.
When I first followed this process, I got a few build errors mainly due to my own daft mistakes in my TypeScript code which I'd set the tsconfig to conveniently ignore. Another error was multiple references for objects, which I managed to fix by deleting the definitions files and making sure that the Generate declaration files option was unchecked in Typescript Build. Once I fixed those issues though, I was able to publish without that annoying error - happy days!
I have a pre-build event in a web project in Visual Studio (2012 but same behaviour in 2010).
The prebuild invoke a simple exe which look for every filename.aspx.vb file if there is a matching filename.html in the folder.
If it does, it just read the filename.html as a string (escaped and minified) and inject it as a string also in the finename.aspx.vb something like :
myStribBuilder.Append("This is where the html code from the external file is going")
Let say i made a modification on filename.html I save and I compile and test the website. It should reflect the latest change when calling filename.aspx
Here what happens :
If I have a very light project with one page or two, it does work. It compiles fine as expected.
Then project get bigger and it doesn't work anymore. I mean code is injected but not compiled as expected, if I refresh filename.aspx on webserver I will still have same version but if I open filename.aspx.vb on VS the code is in there. Second compilation works 100% ok.
I can live with that but I have to compile TWICE each time for testing purpose after html files changes.
This doesn't make sense to me.
What "pre-build" means if in fact it seems to cache the code right on compilation request before executing the prebuild routine.
So, how can I be sure to inject code in my *.vb file before compilation begins ?
I figured out the problem was not VS not waiting for exe to complete on prebuild, but rather having the filename.aspx.vb opened when compiling.
The code update itself on the IDE (with options set to autoupdate externally modified opened page) but I guess the compile process keep the pre-build version of the opened file, which make sense in a way.
If I close the file before compiling it is ok.
Now I wonder if there is a workaround to this, but I understand it is not common practice to externally modify on the fly opened files in IDE before compilation. I do however rely heavily on this technique.