Nextjs/postcss css variables not available in production (Zeit) - javascript

I have a series of variables defining a dark mode theme.
When running the app locally those variables are perfectly loaded.
This is the css inspector:
dark-mode {
--color-bg-bg: #100818;
--color-bg-primary: #100818;
--color-bg-secondary: #1e1528;
--color-bg-almost-primary: rgba(15,8,24,0.8);
--color-bg-light: #0e0917;
}
But if I build the app for production or I deploy it in Zeist those variables are not available.
I thought enabling the custom-properties feature would fix the problem but it doesn't. This is my postcss config file:
module.exports = {
plugins: [
'tailwindcss',
process.env.NODE_ENV === 'production'
? [
'#fullhuman/postcss-purgecss',
{
content: [
'./pages/**/*.{js,jsx,ts,tsx}',
'./components/**/*.{js,jsx,ts,tsx}',
],
defaultExtractor: (content) => content.match(/[\w-/:]+(?<!:)/g) || [],
features: {
'custom-properties': true,
},
},
]
: undefined,
'postcss-preset-env',
],
};
Any ideas? Thanks!

I don't know about zeit, but variables declared in global css are very much accessible from the .module.css files in both dev and production version.

Related

Wallaby Does Not Pass Dotenv Variables to Runner

I am trying to use Wallaby in conjunction with the dotenv-flow package. I currently have my wallaby.js config file setup like below:
require("dotenv-flow").config()
module.exports = function (wallaby) {
return {
files: [
'api/*',
'controllers/*',
'config/*',
'firebase/*',
'helpers/*',
'models/*',
'services/*',
'smtp/*',
'sockets/*'
],
tests: [
"test/**/*.test.mjs"
],
testFramework: "mocha",
env: {
type: "node",
params: {
env: "NODE_ENV=test"
}
}
};
};
I've tried a few other ways of writing the file including in esm module format. However, my tests run and my sequelize code complains that it wasn't passed environment variables to use for connecting to the development DB.
You are loading your .env file but then never using it's contents. Another problem is that wallaby doesn't understand the dotenv output so you have to massage it a little bit.
const environment = Object.entries(
require("dotenv-flow").config()['parsed']).
map( x => `${x[0]}=${x[1]}`).join(';'),
Then change your environment to something like this
env: {
runner: 'node',
params: {
env: environment
}
}

NuxtJS: Disable console.log in production env

I am looking for a way to disable console.log() for production env. Something like putting the below code to nuxt.config.js or index.js:
if (process.env.NODE_ENV !== "development") {
console.log = () => {};
}
I tried it, but it doesn't work. Any help would be appreciated.
My nuxt.config.js is here
https://gist.github.com/somaria/9a2b0e06497d13a35fe9eee141a15d07
Nuxt's build process includes terser, which can be configured to automatically remove console statements from your production build. You could set build.terser.terserOptions:
// nuxt.config.js
export default {
build: {
terser: {
// https://github.com/terser/terser#compress-options
terserOptions: {
compress: {
drop_console: true
}
}
}
}
}
As an alternative, this can also be done with Plugins.
Under Plugins folder, we can create a file called disableLogs.js which can look like so:
// plugins/disableLogs.js
export function disableLogs() {
console.log = () => {};
// or you can override any other stuff you want
}
process.env.NODE_ENV === "production" ? disableLogs() : null;
Then we can register this plugin to be used inside nuxt.config.js
// nuxt.config.js
plugins: [
{ src: "~/plugins/disableLogs.js" },
{ src: "~/plugins/any-other-plugin.js"
],
This will run before instantiating the root Vue.js Application.
There are other things where you can configure it to run either client or server side, etc. More info here - https://nuxtjs.org/guide/plugins#vue-plugins

configure webpack only for production using vue-cli3

I try to compile my vue project a bit differently in local and in production.
As you will see, There is a massive difference in my vue.config.js file...joke
// this is the file when I'm in dev version
module.exports = {
lintOnSave: false,
}
// this is the file when I'm in prod version
module.exports = {
lintOnSave: false,
configureWebpack: {
output: {
publicPath: '/static/'
}
}
}
I was checking for the new mode in webpack 4, or in the vue cli documentation, I didn't find anything which avoid to change the vue.config.js MANUALLY whenever I want to build local or prod. This is not CI ready, and I feel sh*t doing it, so If you guys have any tips to do it properly.
Thanks.
well, I'm not sure that The things to do, but you can use the variable 'process.env.NODE_ENV' in the vue.config.js file (which I didn't expect). so
if (process.env.NODE_ENV === 'production') {
module.exports = {
configureWebpack: {
output: {
publicPath: '/static/'
}
}
}
}
else{
module.exports = {
lintOnSave: true
}
}
looks to work properly

how to test if babel works and my plugins are executed

I'm using Next.js for Server Side Rendering of React application (with styled-components) and have issue with Babel plugins I'm using to show name of the components I'm using in code.
This is my .babelrc file:
{
"env": {
"development": {
"presets": ["next/babel"],
"plugins": [
[
"babel-plugin-styled-components",
{
"ssr": true,
"displayName": true,
"preprocess": false
}
]
]
},
"production": {
"presets": "next/babel",
"plugins": [
[
"babel-plugin-styled-components",
{
"displayName": false,
"ssr": true
}
]
]
},
"test": {
"presets": [
[
"env",
{
"modules": "commonjs"
}
],
"next/babel"
]
}
}
}
When I'm running cross-env NODE_ENV=development concurrently "tsc --watch" next
I'm getting these lines - meaning .babelrc is used during copilation:
[1] > Using external babel configuration
[1] > Location: "...../.babelrc"
[1] > Using "webpack" config function defined in next.config.js.
But once I go to dev tools and see some styled-component I can see this: class="sc-iyvyFf gGaJAt" but on my code I have this definition:
const Title = styled.div`
font-size: 40px;
line-height: 1.13;
`
As it seems from documentation example - I should get something like ... <button class="Button-asdf123 asdf123" /> instead of just <button class="asdf123" />. But I don't.
After going deeper I found this issue ( https://github.com/styled-components/styled-components/issues/1103#issuecomment-324302997 ) based on errors I get in browser console that said:
It seems that only the server code is being transpiled and not the client code 😉
So Question: How to test if babel works correctly and .babelrc is being used in all places?
P.S. In my case those classes that I've got on client side had this prefix sc- meaning in my head styled-components. So I was not sure if the plugin from .babelrc works at all or it works, but I haven't set any special property in declaration of styled-components thus get this general prefix sc-
UPDATE Here is my custom next.conf.js I'm using
const { BundleAnalyzerPlugin } = require('webpack-bundle-analyzer')
const { ANALYZE } = process.env
const path = require('path')
module.exports = {
exportPathMap: function() {
return {
'/': { page: '/' }
}
},
webpack: function(config) {
if (ANALYZE) {
config.plugins.push(
new BundleAnalyzerPlugin({
analyzerMode: 'server',
analyzerPort: 8888,
openAnalyzer: true
})
)
}
config.resolve.alias = {
'styled-components': path.resolve('./node_modules/styled-components/')
}
return config
}
}
Looks like no one has unfortunately answered this before;
What you're seeing probably comes down to this little piece of code you posted: tsc --watch
If you execute TypeScript transpilation before Babel and leave it up to TypeScript to transpile to ES5, it'll transpile all tagged template literals, not giving our plugin anything to hook onto.
Since you're already using next.js you won't need to set up your Babel pipeline from scratch. Rather you only need to disable this type of transpilation in TypeScript.
I'd suggest you to set target inside your tsconfig.json to ESNext so that it leaves everything up to Babel.
https://www.typescriptlang.org/docs/handbook/compiler-options.html (See "--target")

Exclude a module from webpack bundle

I'd like the same functionality like RequireJS empty: http://requirejs.org/docs/optimization.html#empty
My use-case is that I include jquery-migrate in development, but I'd like to exclude this when built for production.
Using IgnorePlugin just makes it not included, and when requireing it in the code, it then throws an error (Uncaught Error: Cannot find module "jquery-migrate").
What I'd like to happen is for it to just return undefined, or something of the like (like empty: in RequireJS). Id like to not touch the import in the code, just configuring it to return undefined.
EDIT: Using NormalModuleReplacementPlugin works, if I point the replacement to an empty file. But keeping an empty file around just for this seems unnecessary.
I use the null-loader for blanking out modules.
The noop-loader can be used for a less awkward if-else in the config.
Try:
rules: [{
test: /jquery-migrate/,
use: IS_DEV ? 'null-loader' : 'noop-loader'
}]
You can try to make a resolve.alias in webpack.config:
resolve: {
alias: {
"jquery-migrate": process.env.NODE_ENV === 'production' ? "empty-module": "jquery-migrate"
}
}
Use Webpack's DefinePlugin in combination with the normal production plugins (Dedupe and Uglify).
Then in your code you can write:
if(DEBUG) {
var test = require('test');
alert(test);
}
And when it's built in production, the DEBUG will be replaced with a literal if(false) { ... } which will be completely removed by the uglify plugin, so test will only be required in a debug build.
Here's a sample Grunt task config for grunt-webpack that has development and production targets for the task:
development: {
devtool: "sourcemap",
output: {
pathinfo: true,
},
debug: true,
production: false,
plugins: [
new webpack.DefinePlugin({
DEBUG: true,
PRODUCTION: false
})
]
},
production: {
plugins: [
new webpack.DefinePlugin({
DEBUG: false,
PRODUCTION: true
}),
new webpack.optimize.DedupePlugin(),
new webpack.optimize.UglifyJsPlugin({
output: {
comments: false,
}
})
]
},

Categories

Resources