So I'm struggling a bit with this. Let's say I build my NextJS project, I have 2 css files one of them is 10mb. Then I run next start and I see on Lighthouse that the file size is only a few kb. But if I run node server.js on the standalone folder, the css file size stays the same and that's a problem. Is this the intended behavior? Is there any way to fix this?
When I say standalone folder I mean this: https://nextjs.org/docs/advanced-features/output-file-tracing#automatically-copying-traced-files-experimental
UPDATED
I think you're trying to build custom server (https://nextjs.org/docs/advanced-features/custom-server)
According to that document, they mention this part which may be related to what you're looking for
Before deciding to use a custom server, please keep in mind that it
should only be used when the integrated router of Next.js can't meet
your app requirements. A custom server will remove important
performance optimizations, like serverless functions and Automatic
Static Optimization.
OLD ANSWER
next start usually goes along with next build (https://nextjs.org/docs/api-reference/cli#production) and it has its own custom configs under next.config with a ton of good stuff like file compression, routings, image optimization, etc. (under the hood, it also uses Webpack and Babel for builds)
node server.js is just simply to run a server and does nothing else. Therefore, if you want to have better builds like NextJS. You need to add libraries into NodeJS.
You can find some useful libraries here.
https://blog.bitsrc.io/23-insanely-useful-nodejs-libraries-you-should-know-in-2020-5a9b570d5416
Related
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>
This may be a problem that others have had before, but I've not been able to find the right search terms if so.
I am using LESS CSS (a CSS pre-processor) in my webapp, and I need it automatically compile a CSS file whenever a LESS file is saved, such that I can just refresh my browser and see the changes. I have previously been successful in doing this by changing the project properties in MyEclipse, in order to point at an external maven executable, and the generate-sources phase within my project's POM.
We're now in the progress of transitioning to GIT (very slowly), and as a step on that path, we want to ensure none of the project files are in version control. Obviously this means that setting up an external executable in the project files is no longer viable, if I want all developers to automatically have this happen for them.
Can anyone please point me in the right direction for solving my problem?
You could try the web resource optimizer for java (aka wro4j). It can apply less css processor (or many other processors) using both: runtime solution (as a filter) or build-time solution (as a maven plugin with m2-wro4j eclipse plugin which is capable of identifying incremental builds).
Alternatively, there is a lightweight solution which process the less resources on the fly, using the LessCssFilter
I'm considering using LESS for CSS development with server (or development) side processing, but I can't decide if I should keep the generated CSS files in version control. There are plenty of solutions with hooks, but this adds software dependencies to the server. A hook could just be added locally so staging and production areas on the web would get the same files. So, the question is:
Should generated CSS files be included in version control or not? Please keep in mind that some frameworks require a CSS file to exist for a particular reason (i.e. WordPress themes require a style.css file in order to be recognized).
When I say 'considering using LESS', I mean it becomes a requirement. New developers would not have the option use vanilla CSS after the choice is in favor of LESS.
Checking in derived artifacts is almost always sub-optimal.
I vote no to checking in the .css. It's only a matter of time until one of your peers or successors checks in an edit to the .css and not the .less. Then when you change the .less the prior change is lost.
You've pretty much answered your own question. It depends on how you deploy your website.
If the server is just going to pull directly from the Git repository:
1) It needs to have software installed to generate CSS from LESS.
2) or you need to include the CSS files in the repository.
If you're not pulling straight from the repository on your web server, you could have a build script that pulls from git, generates CSS, and then transfers the content to the web server(s), possibly excluding unnecessary files from the transfer.
In my opinion, Git should be used to keep all of the source for a project, and none of the "derived artifacts" (as mentioned by #thekbb). Developers need to have all tools installed to generate those derived artifacts during development and test. For deployment to test and production servers, an automated build server should take the source and create just the files needed for distribution.
In the case of software development, you'd have a Makefile with .C and .H files (for example) in your Git repository. Developers and the build server have a compiler installed that will create an executable or compiled library. When the files are packaged for distribution, the source code is not a part of the archive.
For web development, you have source files like original graphics, HTML templates and LESS files. Developers and the build server can run scripts to generate the site assets (CSS from LESS files, static HTML pages from templates, flattened images in multiple sizes/formats, etc.) When the build server deploys new builds, it copies just the files needed by the server, excluding the source graphics, templates and LESS files.
If there are people that need to review the site content, they should do it on a staging server. If that's not possible, the automated build server can create a ZIP file on an internal server that they can download for review.
Should generated CSS files be included in version control or not?
In theory they should not, but for practicality, I do usually checks in the generated css file. The reason is that it simplifies deployment since I do deployment using git; I would not need to have a less compiler installed on the server and usually not even on the machine I'm deploying from (as opposed to the machine where I'm developing on). Doing this could be useful if you have separate developer and deployer, but can sometimes also be useful even if you're deploying yourself.
Now, there are drawbacks on doing this:
You can't use git add --patch (or you really need to be very careful when doing so)
You should not modify the .css directly; instead I usually use a secondary .css file to do minor modifications without modifying the primary .less or .css file. You can also compile .less file straight into a minified css, to make it less tempting to modify the generated css.
Developers have to set up their machine to use automatic recompile tool (like SimpLess or Less.app), so the .css file is updated as soon as they save to the .less file. Without automation, you'll run into risk of the css not matching the checked-in less file.
I would not do the same when compiling from .C and .H files though, because the generated binary for those are platform specific, and also .less/.css file is usually a very small part of a larger web project so the space overhead of the additional file is small.
Good question. If you can absolutely guarantee that the CSS file gets updated when the LESS gets updated then perhaps yes - as per #Scott Simpson's comment. I suspect that this would be difficult to guarantee and what happens when the new developer get's a copy of CSS the day when they are out of sync? Also, of course, and I hadn't originally thought of this, what happens if the new developer then makes updates to the CSS file rather than the LESS?? If the CSS has to be built and isn't part of archive I can see less problems.
I would say yes -- because what happens if you want to add a developer to your workflow and they don't want or need to build .Less? It would be helpful for them to have access to only the generated file.
I would like to issue one command to build both a grails and a flex project (the Flex project can be built with Ant). I have a file, WEB-INF/flex/services-config.xml which needs to be different for the PROD war build and the DEV environment.
I'm thinking of having two files: services-config-PROD.xml and services-config-DEV.xml and then copying the relevant one to services-config.xml whenever a build happens.
So in dev I run 'grails run-app' and it copies the file and runs the app; and for prod I run 'grails war' (or some other command) and it copies the file, creates a war, and also calls the Flex project to build via its Ant build file.
What would be the best way to acheive this, or at least any part of what I'm asking?
Seems overly complicated. Why do you need the services-config? Personally, I never use it, I use code to create my services which can be done dynamically if needed. If you want one for prod or dev, you can all do it within code.
I would imagine that prod and dev is just 2 different server urls? I normally let html pass those urls using FlashVars. That way, both servers can point to exactly the same swf (or different swf versions), but just change that one FlashVar to make the application point at a different location.
Setting up Flex project for group development can be a bit tricky. There are lots of little local settings that might need to be tweaked in order to have a project that can be easily checked out.
I've had limited success using the built-in import/export flex project utilities. I seem to wind up editing by hand a lot and I think I might be missing something.
UPDATE
I neglected to mention originally that my goal is to make it possible to checkout a project from subversion and get up and running with as little fuss as possible. The biggest problems that I have run into all revolve around managing the "dot" files and how to make them flexible enough to deal with different developer environments.
For example, even with just me, I would like to have this ability: at work, I use a Vista machine and at home I use a Mac. There are certainly differences in the way certain paths are described, but they really are quite similar. On Vista, the flex root is c:/ColdFusion8/wwwroot, on OS X, it is /Applications/ColdFusion8. I have been able to set up a linked resource path variable for both CF_FLEX_SERVER and WEBSERVER that I then reference using the ${WEBSERVER}/myProject syntax.
So far, it seems to work pretty well, but I find there are a few places that it still has issues. Specifically, in the .project file you find something like:
<linkedResources>
<link>
<name>bin-debug</name>
<type>2</type>
<location>c:/inetpub/wwwroot/myProject-debug</location>
</link>
</linkedResources>
Unfortunately, if I try to change the location entity to ${WEBSERVER}/wwwroot/myProject-debug, flex throws a compiler error. That's a shame, because pretty much everything else works.
I have worked through this problem before and generally set my projects up as such:
Application/trunk/source/ <-- workspace is here (can also be in 'trunk')
Application/trunk/source/Application <-- Application here
I DO keep my project (.actionScriptProperties, .flexProperties, .project, .settings) in SVN, but NOT my workspace (.metadata) because it's too big.
I find that importing projects via Import -> Flex Project enforces alot of restrictions. For example, if your workspace was in the 'trunk' directory above then importing as a Flex Project will cause the project to be copies into trunk/Application or simply complain about the location.
The better way to go about it is to create the workspace and then Import -> [General] Existing Projects into Workspace. The only difference is that you will have to manually add the Flex Development perspective.
Edit: I'd also recommend setting your compiler options to "Use default SDK" and then setting the appropriate SDK as default. This will prevent commit-tennis when each developer names his SDK differently.
Since Flex Builder is written on top of Eclipse, it can integrate with Subclipse. This allows you to pretty easily tag files as 'SVN ignore' to avoid project-specific settings. I've used this to add my Flex projects to an existing SVN repository, which I've checked out to multiple sites. I have noticed a few issues here and there (some checkins get errors, but they're relatively rare), but it generally works.