I've started with a template from this extension to have a running angular2+ .net core starting point. I didn't want to use boostrap, but materialize-css, so I removed the bootstrap package in package.json, instead I added "materialize-css": "0.98.0",
Then I edited the webpack.config.vendor.js, I removed bootstrap and added materialize-css to the "vendor" list.
Then I rebuilt everything, but it seems that materialize-css is still not present(cannot find its css classes). I tried to clear the browser cache, tried even to open on a brand new browser(edge), but still, no materialize-css classes.
What did I miss?
EDIT
Currently, my vendor list is the following:
vendor: [
'#angular/common',
'#angular/compiler',
'#angular/core',
'#angular/http',
'#angular/platform-browser',
'#angular/platform-browser-dynamic',
'#angular/router',
'#angular/platform-server',
'angular2-universal',
'angular2-universal-polyfills',
'materialize-css',
'es6-shim',
'es6-promise',
'jquery',
'zone.js',
]
You're doing everything correctly, just need to do one thing slightly differently. In your webpack.config.vendor.js, instead of materialize-css, add materialize-css/dist/css/materialize.css to the vendor array:
...
entry: {
vendor: {
...
'materialize-css/dist/css/materialize.css',
...
}
}
This will include the css to your resulting bundle. If you also need fonts and js from materialize-css, you'll need to configure appropriate loaders, see https://www.npmjs.com/package/materialize-loader
Related
Summary
The project works without issues with SASS modules.
Trying to use SASS inside src/cms/cms.js for the purposes of customizing the CMS admin preview panel breaks the project.
Using regular CSS or CSS modules works without any problem for the admin preview panel.
I've checked for this issue on GitHub, the Netlify CMS forums and documentation, Stack Overflow, and everywhere that Google has led me.
Describe the bug
My project uses Netlify CMS and Gatsby. I have no issues with SASS when working on the project. The issue only comes up when I try to use SASS inside components that I want to use as custom preview with CMS.registerPreviewTemplate() for the CMS Admin panel at http://localhost:8000/admin/.
I've setup up everything without any issues and there are no problems when I use CSS modules.
The problem is that my project uses SASS and when I just rename import * as styles from PreviewTesting.module.css to import * as styles from './PreviewTesting.module.scss' inside PreviewTesting.jsx I get this error:
ERROR Failed to compile with 1 error 6:03:26 PM
⠀
error in ./src/templates/previewTesting/PreviewTesting.module.scss
⠀
Module parse failed: Unexpected token (1:0)
You may need an appropriate loader to handle this file type, currently no loaders are configured to process this file. See
https://webpack.js.org/concepts#loaders
> .previewTestingDescription {
| background-color: lightgoldenrodyellow;
| font-family: 'Montserrat-Regular', sans-serif;
Also, just adding import '../styles/global.scss' inside the src/cms/cms.js file causes the same error that prevents the build from happening.
I've tried updating and downgrading any package I could think of and this did not help. I've also tried to register the files as preview styles with CMS.registerPreviewStyle(file); and I've tried Raw CSS with https://www.netlifycms.org/docs/beta-features/#raw-css-in-registerpreviewstyle. None of these solved the issue.
To Reproduce
Steps to reproduce the behavior. For example:
Create a React component.
Import a SASS module component into the React component.
Register that component as a preview component with CMS.registerPreviewTemplate('name', PreviewTesting) inside src/cms/cms.js
An alternative way to reproduce:
Add import '../styles/global.scss' inside the src/cms/cms.js. global.scss hold regular SASS things like imports for fonts, variable and other such things.
Expected behavior
The project should run and apply the CSS styling to the preview panel at http://localhost:8000/admin/
Screenshots
Applicable Versions:
"gatsby": "^4.9.0"
"gatsby-plugin-netlify-cms": "6.25.0"
"gatsby-plugin-sass": "5.25.0"
"netlify-cms-app": "^2.15.72"
"sass": "1.49.9"
"gatsby": "^4.9.0" (updated to the latest version "4.25.1")
Node.JS version:
Did not work on v16, updated to v18.12.1, still does not work.
CMS configuration
collections:
- name: "name"
label: "names"
label_singular: "name"
description: >
Test
create: true
slug: "{{category}}-{{slug}}"
fields:
- { name: title, label: Title }
- { name: subtitle, label: Subtitle, required: false }
Additional context
Any help would be very appreciated.
A friend of mine provided me with a solution:
The plugin order in gatsby-config.js actually matters in this case. gatsby-plugin-sass must come before gatsby-plugin-netlify-cms
The plugin segment in gatsby-config.js should look like this:
{
resolve: 'gatsby-plugin-sass',
options: {
additionalData: '#use "/src/styles/global" as *;',
sassOptions: {
includePaths: ['src/styles'],
},
},
},
{
resolve: 'gatsby-plugin-netlify-cms',
options: {
modulePath: `${__dirname}/src/cms/cms.js`,
},
},
To set the context I am creating a CRUD application for Laravel. It is installed via composer and the sources are therefore in the vendor/organization/package directory.
In my project, I use Datatable. So I use Laravel Mix to compile my sources and a command line allows to copy JS and CSS compiled files into the public directory of the Laravel Host application.
I would like however that the developers who will use my library can customize the display of some Datatable cells. To do this you must use Datatable's createdCell configuration.
$('#example').dataTable( {
"columnDefs": [ {
"targets": 3,
"createdCell": function (td, cellData, rowData, row, col) {
if ( cellData < 1 ) {
$(td).css('color', 'red')
}
}
} ]
});
The problem is that the JS sources of my project are already compiled...
For the moment I found a temporary solution that consists in leaving the JS sources in vendor/organization/package but copying the webpack.mix.js configuration into the Host application and asking the developers to compile themselves. The problem is that all JS dependencies must also be installed and it doesn't take very seriously to force the developers to compile sources before being able to use my library.
What are good practices to achieve this objective?
The following source may help, but I confess I don't know how to apply it to Laravel:
How to bundle vendor scripts separately and require them as needed with Webpack?
Thank you for your help.
Sorry for the obfuscated question, I'll elaborate my problem. I am currently developing a single page app in Aurelia, and I found a lib I want to try out: https://github.com/hootsuite/grid. I did the normal jspm routine:
jspm install github:hootsuite/grid
which installs successfully and adds the following to the systemjs config:
map: {
"hootsuite/grid": "github:hootsuite/grid#1.0.0",
The package file looks like this:
define(["github:hootsuite/grid#1.0.0/src/gridList.js"], function(main) {
return main;
});
Which enables me import the module as expected:
import * as grid from 'hootsuite/grid';
So far so good, but the js file referenced by the module is not the one I am interested in (src/gridList.js), the src folder also contains a jquery plugin named "jquery.gridlist.js" which is the file I actually want to resolve. I managed to "fix/hack" it by adding an additional AMD module definition in the module file (grid#1.0.0.js):
define('gridlist', ["github:hootsuite/grid#1.0.0/src/gridList.js"], function(main) {
return main;
});
define(["github:hootsuite/grid#1.0.0/src/jquery.gridList.js", "github:hootsuite/grid#1.0.0/src/gridList.js"], function(main) {
return main;
});
This is not a viable solution because the jspm_modules are not a part of source-control, thus it will have to be patched manually for every dev. So, whats the best approach for this type of problem? Or which features am I missing out on which removes the problem entirely?
We are attempting to override the behavior of Bundle Products in Magento2, specifically, to enable user defined quantities for Checkbox type products within the bundle.
We have written an extension, and followed instructions about how to replace a default JS component found here: http://devdocs.magento.com/guides/v2.0/javascript-dev-guide/javascript/custom_js.html
Our requirejs-config.js within our extension's frontend (app/code/Endertech/BundleExtended/view/frontend/) view looks like:
var config = {
"map": {
"*": {
'Magento_Bundle/js/price-bundle': "Endertech_BundleExtended/js/price-bundle"
}
}
};
This is having the effect of loading BOTH the core Magento2 price-bundle.js AND our modified version... and the customization we've added to our modified version is not executing... presumably because the Magento2 core version is loading first.
We expected for this revision to PREVENT the core version from loading in favor of ours.
Perhaps we are approaching the problem from the wrong direction, or have some other misunderstanding.
We are seeking a solution to have our modified price-bundle.js be loaded in lieu of the built-in that comes in the Magento Bundle module... or at least a way to override specific methods within and is required here (vendor/magento/module-bundle/view/frontend/requirejs-config.js).
If our approach is wrong, we'd be happy to be corrected!
I have YUI project that is mavenized. When we release new YUI code, it is not reflected right away in the browser, until you do SHIFT + REFRESH on browser.
I have been using YUI modules approach to load scripts like this:
YUI.GlobalConfig = {
modules: {
'manual-entry-util': {
fullpath: 'resources/js/common.js',
requires: [ 'node']
},
'user-perm-util' : {
fullpath: 'resources/js/userPermUtil.js',
requires: [ 'node', 'io-base', 'json', 'json-stringify']
},
'file-upload-custom' : {
fullpath: 'resources/js/fileUploadCustom.js',
requires: [ 'gallery-datatable-selection','event-custom', 'node']
},
'icsd-uploader' : {
fullpath: 'resources/js/icsdUploader.js',
requires: [ 'uploader', 'node']
},
'ui-util' : {
fullpath: 'resources/js/uiUtil.js',
requires: [ 'node']
}
}
};
I believe we need to modify the urls to have some sort of variable so that new code can be picked up by the browser.
Is there a way to automate this process via maven or some other tool. E.g. which can generate the hash value from the contents of the .js file and then add that to the url of .js file?
My approach has been to include a cache-busting value at the beginning of the path to your resources. An appropriate value might be the current abbreviated commit hash or revision number, or if using a CI tool, the current build number. Your build process would deploy all of your assets into a directory named with this value, so if your current commit hash was abcd1234, you would end up with files in something like resources/abcd1234/js/.
Your build process would need to also dynamically modify your YUI.GlobalConfig object, perhaps using token replacements, so that the YUI Loader could find your files there. This could be done in one spot by setting the base configuration option (see http://yuilibrary.com/yui/docs/yui/loader.html#configuration-options), but since you're specifying the fullpath for each file, you'd have to set each of these.
During development, you'd have to continue hard reloading your pages (as you're doing now with SHIFT + REFRESH), but your users will cache each version of your resources separately.
We use a variant of the answer from #blicksky. We built our own combo-loader as a servlet.
Firstly, we set up YUI as it's own Maven project. The version tag reflects the release of YUI, so your version would look like <version>3.17.2</version. We have an in-house repo, so any update to the YUI project gets published there. The YUI project just houses a copy of YUI in /src/main/resources/META-INF/resources. In this respect it's pretty similar to the approach taken by the WebJars project.
The Combo-loader takes care of concatenating the YUI files together for better loading performance and is also responsible for adding a cache-busting URL parameter. In production that parameter is the Build ID, but in development, that parameter can be a random number, so that the resources are loaded each time. We're using Spring on the server, so we use the Classpath to resolve YUI files that come from the YUI Maven project mentioned above. The basic gist is that our Servlet implements ResourceLoaderAware and can then use the ResourceLoader to pick up YUI files to serve up.
The approach has served us well and also allows us pretty fine-grained control of how the files are served, as well as improving load-times.