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!
Related
I'm doing Django project, my issue is when I change colors in style.css file in static folder, the changes aren't reflecting on the website again the same old colors are coming.
ScreenShot of my project file directory
Unlike with Python files, Django doesn't automatically refresh the server each time a static file is updated. What most official sources recommend is running py manage.py collectstatic.
This often doesn't work (at least for me), but all CSS changes are usually implemented after a complete reboot.
So try saving, closing all your files, then restarting your computer. It's a simple workaround, but it's often reliable.
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!
Using Visual Studio Express 2013 for Web
Set up bundling and caching as generally described here: http://www.asp.net/mvc/overview/performance/bundling-and-minification
In the VS Solution Explorer, individual file properties for .js and .css files are set to Build Action: Content. I don't know if this was specifically set or a default setting.
When deployed in Debug Mode, individual files are deployed to the destination server's directory structure as expected and the rendered code in the index.aspx head section has a long list of for each individual javascript and css file configured, again, as expected. When loaded, I can see that the files are being loaded individually. Everything works.
When deployed in Release Mode, however, individual files are still being deployed to the destination server's directory structure, non-bundled and non-minified. Index.aspx DOES reflect a rendered reference to each bundled "file" using . When loaded, I can see that things are being loaded via the bundle.
In Release Mode, the individual files deployed to the destination server's directory structure seem to be redundant, and certainly unwanted. However, if I remove them post-deploy I get reference errors. Similarly, if I change file properties for each file's Build Action: Content to Build Action: None, the aforementioned individual files aren't deployed in Release Mode OR Debug Mode and I get reference errors in both scenarios.
Question 1: Am I misunderstanding how bundling and minification works and these individual non-bundled, non-minified files are indeed required in Release Mode?
Question 2: If I understand correctly that these non-bundled, non-minified files are NOT necessary in Release Mode, how do I configure the deploy correctly such that they ARE deployed in Debug Mode and ARE NOT deployed in Release Mode AND I get no reference errors?
Answer 1: Bundling and minification are done at run-time, not at build, compile, or deploy time. The "bundle" that is downloaded is a virtual file, it doesn't actually exist anywhere on disk. Thus the original "source" files are needed.
Answer 2: Sorry but your understanding is not correct. The non-bundled/minified files are required in Release mode as they form the basis for creating the bundled/minified payload that is sent to the client.
I'm running JetBrains ReSharper 8.2 on a project that uses SASS for styling.
I compile my seperate scss files into one file "common.css". This file is not included in the project, but gets compiled on build on the server (grunt + compass takes care of this).
I don't want to include this file, but only my SCSS files in the project. This however causes ReSharper to report a lot of errors ("Unknown CSS class"...) in my views because the file isn't included.
Is there a workaround for this (without disabling css errors in settings)?
I've tried the "ReSharper.ExternalCode" extension (https://resharper-plugins.jetbrains.com/packages/ReSharper.ExternalCode), but without any luck.
Sadly, there isn't a workaround for this. ReSharper doesn't know about SCSS files, and doesn't know anything about files that aren't included in the project, so it can only assume the CSS classes are undefined.
The external code plugin should work and allow ReSharper to process the resulting css file. However, I'm not sure how flexible it is - I think it needs everything to be configured before the solution is opened. That is, it only tells ReSharper about the generated file when the solution is being opened. Configuring things while a solution is open probably won't be reflected immediately (but I haven't tried it). Similarly, it doesn't notify ReSharper of changes to the file, and I don't think that ReSharper sets up any monitoring. So if the file isn't available when the solution opens, or changes while it's open, ReSharper won't have correct information. I'd try and configure it, close the solution and reopen.