I tried to execute the minimal rollup example that ag-grid shows at their page. But no matter what, I won't get it to work. The Error I get is:
ag-Grid: could not find matching row model for rowModelType clientSide
Row Model "Client Side" not found. Please ensure the ClientSideRowModelModule is loaded using: import '#ag-grid-community/client-side-row-model';
I tried importing ClientSideRowModelModule and ClientSideRowModel, as stated in the error, but that changes nothing.
I tried and stepped through the bundled code and it seems that it is not possible for aggrid to access their own modules, although they are present.
I uploaded the example to github, just clone, npm i && npm run rullup and then open the index.html file.
https://github.com/dennis-f/ag-grid-clientsiderowmodel-bug
git clone git#github.com:dennis-f/ag-grid-clientsiderowmodel-bug.git
npm i && npm run rollup
Okay I managed, to get it to work.
Old:
import {Grid} from '#ag-grid-community/all-modules';
New:
import {AllCommunityModules, Grid, ModuleRegistry} from '#ag-grid-community/all-modules';
ModuleRegistry.registerModules(AllCommunityModules);
I don't know why this is missing in all those examples, but you need to register your modules manually, even if you use the 'all-modules' package.
It is not aware, that all modules should be loaded on startup. It's a nice solution, but unfortunately it's only explained here.
Instead of AllCommunityModules you can obviously load only the ones you actually need.
Related
I am working through the Odin Project and am stuck on the first lesson where we must build a webapp using webpack. I followed the tutorials here and hereon webpack's website, and I was able to get them to work. However, when I try to set up my own files to build my own project, I can't get CSS to load or a function in my index.js file.
I have the same directory style set up, and have even tried using the exact same index.js file they use in the tutorial.
I expect to get: a webpage to load that says "hello webpack" in red text.
Instead, I get this error: when I run $npx webpack, it says:
ERROR in ./src/style.css 1:0
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
> .hello{
| color: red;
| }
# ./src/index.js 1:0-21
Upon googling the error, I found a stack overflow article and I tried renaming my rules array to 'loaders' in my .config file as this article suggests, but I still get the same error.
“You may need an appropriate loader to handle this file type” with Webpack and CSS
Also weird is the fact that some of the code in my index.js file works, and some does not. To elaborate, my console.log and alert works just fine after I run $npx webpack and load the page. However, they function that is supposed to add "hello webpack" to the DOM, does not, as evidence by the fact that nothing shows up at all. The page itself is blank.
My index.js code:
import './style.css';
console.log("console works");
alert("alert works");
function component() {
const element = document.createElement('div');
// Lodash, now imported by this script
element.innerHTML = _.join(['Hello', 'webpack'], ' ');
element.classList.add('hello');
return element;
}
document.body.appendChild(component());
You will notice that it is nearly the exact same as the asset management index.js file from the webpack tutorial. I did this purposely to have as little variance as possible between my stuff and the tutorial.
I don't know if it is too much information, but a link to the whole repo as it currently is set up can be found here
Update:
I re-setup the file from the ground up and noticed that the CSS stopped working when I went out of my way to change the bundle.js link they had in their example to main.js. While I double-checked to make sure that I made the correct corresponding changes to output in my config file, making this change had the sum total outcome of not allowing my CSS to work for some reason.
What this reason is? I have no idea, and would be very interested to learn why this happened if someone has a suggestion
But on the offchance that one of my fellow Odin learners googles this problem, I kept the example's bundle.js instead of changing to main.js as my output script and it worked fine.
I'm going to update my github now so my original github link will likely be out of date going forward.
Going through your GitHub repo commit history, I see that at some point you named your Webpack configuration file weback.config.js instead of webpack.config.js (the p was missing). This was likely the source of the problem, as Webpack couldn't find a loader configuration for the .css file you're importing.
This is odd. Following along with the tutorial, I'm attempting to create a group of routes. However, the actual Routes element cannot be found:
The BrowserRouter and individual Route elements seem to be working fine, however.
I'm using the latest version of React Router Dom (6.2.1). Any ideas?
It might happen because of conflicting typings the IDE auto-downloads to its configuration folder for better code completion. You can remove the auto-downloaded typings from <IDE system dir>\javascript\typings (shut down the IDE first) and either disable typescript.external.type.definitions Registry key or remove react-router-dom from typescript.external.type.definitions.packages key value
The Registry can be located via: Help > Find action > type Registry...
Appears to be a PhpStorm issue. Viewing the project in VS Code gives no errors on the element, and shows its signature and location:
Whereas the problem persists in PhpStorm even after a restart.
I would like to use valid-url to validate some URLs using JSFiddle so that I can share it later. I tried adding a link to the index.js file from Github (https://raw.githubusercontent.com/ogt/valid-url/master/index.js) but Fiddle says:
Github is not a CDN, using it as such will cause issues with loading the file. Do you still with to it?
And obviously when I try to use it, an error is thrown:
Refused to execute script from [...] because its MIME type ('text/plain') is not executable, and strict MIME type checking is enabled.
So, is there any way to use npm packages in a JSFiddle? Or any workaround to achieve this?
Use unpkg.com. They allow you to load any npm module from the browser like a CDN.
Using UNPKG you can load any file from any package following this pattern
https://unpkg.com/:package#:version/:file
So, if you add
https://unpkg.com/valid-url#1.0.9/
Then you'll get this (as shown in the next image)
If you specify the index.js file
https://unpkg.com/valid-url#1.0.9/index.js
Then you'll get this (as shown in the next image)
You'll then be able to use it in your fiddles by adding the Resources you want to.
If you want to import something from npm on the frontend, you can use https://www.skypack.dev/ which converts npm modules to ES Modules, example:
<script type="module">
// Use 'https://cdn.skypack.dev/' + 'npm package name' + '#version its optional'
import random from 'https://cdn.skypack.dev/canvas-sketch-util#1.10.0/random'
console.log('A random number: ', random.range(1,10))
</script>
Here's a JSFiddle using SkyDev to load an npm module.
There are many cases that https://unpkg.com/ wouldn't handle that https://www.skypack.dev/ can, so I recommend using it whenever it's on the front-end
I wrote a slightly more complete answer here about this:
How can I use a CommonJS module on JSFiddle?
Just ran an npm update on my web application and now Moment JS appears to be failing with the following message:
Error: Cannot find module "./locale"
\node_modules\moment\src\lib\moment\prototype.js:1
> 1 | import { Moment } from './constructor';
Not sure what version of Moment JS I had prior to my update, but my application has been working for months.
I created another react app and ran an npm install moment --save and modified the source to display the time and ended up with the same error described above.
Not sure if there is a fail-proof way to integrate Moment JS using Create-React-App currently short of ejecting to manage the webpack settings myself, but I really don't want to do this. Anyone else seeing these issues or having success? If so, a short write up would go along way to helping out.
Appears this has already been identified as an issue for Moment JS version 2.19. If you have upgraded to 2.19 run npm install moment#2.18.1 to revert back to previous version until it is fixed!
See thread: https://github.com/moment/moment/issues/4216
Application built with Create React App and using Moment 2.24.0, the following seems to be working fine:
import moment from 'moment';
import 'moment/min/locales';
Instead of importing moment-with-locales directly. Alternatively, also possible to only import required locales:
import moment from 'moment';
import 'moment/locale/fr';
import 'moment/locale/ru';
The answer above, though I have no doubt works for some, does not work for me. The solution I found is fairly quick and easy, but is a little more complicated than simple downgrading.
This problem originates as a result of and can be fixed with webpack. So we're going to have to add a few lines of code to our webpack.config.js file. If you don't have one yet, you can add one to the root webpack directory:
YOURAPPNAME/node-modules/webpack/
So now that you're inside your webpack.config.js file, you need to add a few lines of code. Just copy and paste this inside the new file or adapt it to the code you already have in webpack.config.js.
module.exports = {
resolve: {
alias: {
moment$: 'moment/moment.js'
}
}
};
Your import statement of moment in your index.js (or otherwise named) file should look like this:
import moment from 'moment'
You should now be able to use moment completely normally. For example:
var tomorrow = moment().add(1, "day")
If you have a fresh install, or upgraded moment to 2.25 and are getting this warning now, try forcing all your packages to use 2.24.
UPDATE: New release 2.25.3 has been reported to fix this problem! Try to first just update.
If you depend on some library that didn't upgrade yet, tell them to upgrade. And in the meantime, if you need 2.25, you can force also your sub-dependencies to use this version.
If you're using yarn add these lines into package.json
"resolutions": {
"**/moment": ">=2.25.3"
},
This is to be added inside packages.json at the top level, i.e. with the same indentation as "dependencies".
I decided to try out WebPack on a new project I'm spinning up today and I'm getting really strange behavior from the sourcemaps. I can't find anything about it in the documentation, nor can I find anyone else having this issue when skimming StackOverflow.
I'm currently looking at the HelloWorld app produced by Vue-CLI's WebPack template -- no changes have been made to the code, the build environment, or anything.
I installed everything and ran it like so:
vue init webpack test && cd test && npm install && npm run dev
Looking at my sourcemaps, I see the following:
This is a hot mess. Why are there three version of HelloWorld.vue and App.vue? Worse yet, each version has a slightly different version of the code and none of them match the original source. The HellowWorld.vue sitting in the root directory does match the original source, but what's it doing down there instead of in the ./src/components folder? Finally, why isn't there a fourth App.vue that has the original source for it?
As far as I can tell this may have something to do with the WebPack loaders. I've never gotten these kinds of issues with any other bundler, though. Below is an example of the exact same steps using the Browserify Vue-CLI template:
No webpack:// schema, only one copy of every file, the files actually contain the original source code (kind of important for source maps), no unexpected (webpack)/buildin or (webpack)-hot-middleware, no . subdirectory,.... just the source code.
I haven't worked with Vue so can't really describe how exactly this is happening but it seems to be related to Vue Loader. Looking at the documentation I did not really find anything that clarifies why it would create three different files for one component. But it does seem logical considering that a .vue file might contain three types of top-level language blocks: <template>, <script>, and <style>.
Also, looking at two of those files you do see a comment at end of each file that suggests it was modified in some way by a Vue loader. Either this
//////////////////
// WEBPACK FOOTER
// ./node_modules/vue-loader/lib/template-compiler
or
//////////////////
// WEBPACK FOOTER
// ./node_modules/vue-style-loader!./node_modules/css-loader
The third file is different but it still does have code that identifies it as being modified by Vue loader. Here is some of that code
function injectStyle (ssrContext) {
if (disposed) return
require("!!vue-style-loader...")
}
/* script */
import __vue_script__ from "!!babel-loader!../../node_modules/vue-loader/..."
/* template */
import __vue_template__ from "!!../../node_modules/vue-loader/..."
/* styles */
var __vue_styles__ = injectStyle
The document also says this:
vue-loader is a loader for Webpack that can transform Vue components written in the following format into a plain JavaScript module:
Which explains why you might not see the same type of behaviour with other bundlers.
Now, This might not be the answer you were looking for but just wanted to share what I had found.
This is actually a feature of webpack.
webpack has HMR (Hot Module Reloading). If you look in your network tab, go ahead and make an update to your HelloWorld.vue file. You'll see a js chunk come thru as well as an updated JSON manifest. Both of these will have a unique hash at the end for each time you make a change to the application. It does this so the browser does not have to do a full reload.
For a better explanation of this I would highly recommend reading through https://webpack.js.org/concepts/hot-module-replacement/