I am trying to add material desing to jhipster generated gateway. Although it seems it is working I am getting this warning on console;
Could not find Angular Material core theme. Most Material components may not work as expected. For more info refer to the theming guide: https://material.angular.io/guide/theming
Could not find HammerJS. Certain Angular Material components may not work correctly.
Below lines are added to package.json dependencies
"#angular/material": "^2.0.0-beta.7",
"hammerjs": "^2.0.8",
Below lines are added to global.scss
#import url('https://fonts.googleapis.com/css?family=Roboto:300,400,400i,500,700');
#import '~#angular/material/prebuilt-themes/indigo-pink.css';
Just note that if I comment out indigo-pink.css line UI becomes uglier so I conclude that this css is imported successfully when not commented.
Jhipster version is 4.5.6
What can be the reason for the warning
Edit 1: this solves the hammerjs warning https://stackoverflow.com/a/41322757/795168 , but still theme warning and problem on UI is continues
Adding angular material to monolothic jhipster project worked for me by deleting hammerjs if it is installed
npm uninstall hammerjs --save
and verify that is deleted in package.json file
Install the #angular/material library and add the dependency to package.json
npm install --save #angular/material
Import the Angular Material NgModule into your app module...
import { MaterialModule } from '#angular/material';
#NgModule({
imports: [
...
MaterialModule
],
...
})
Now that the project is set up, it must be configured to include the CSS for a theme. Angular Material ships with some prebuilt theming, which is located in node_modules/#angular/material/prebuilt-themes/.
To add an angular CSS theme and material icons to your app
#import '~#angular/material/prebuilt-themes/deeppurple-amber.css';
#import '~https://fonts.googleapis.com/icon?family=Material+Icons';
please check with the link Install Angular Material
Related
I am trying to setup swiper.js in my ionic angular project. (Using the [ionic documentation])(https://ionicframework.com/docs/angular/slides)
When trying to import the module I get the error 'Cannot find module 'swiper/angular' or its corresponding type declarations.
When checking the node package there is no angular folder in the swiper package.
Swiper: 9.0.1
Node: v14.19.1
Angular 14
ionic: 6
Using the ionic documentation
npm i --save swiper
in app.module.ts I get the error when trying to import the swiper module:
import { SwiperModule } from 'swiper/angular';
Screenshot of code line
The contents of the swiper node package:
Screenshot of swiper folder contents
Swiper Version 9 doesn't have support this. They stopped supporting angular in an 'angular' way.
The recommendation is to use Swiper elements, which requires some re-learning of swiper.
Follow the links through this page to get set up.
https://swiperjs.com/angular
Let say I have following component:
#Component({})
export class ServerComponent {
}
When typing #Component, Visual Studio Code suggest me to auto import #angular/core module. I accepted and get this import:
import { Component } from "../../../node_modules/#angular/core";
When I watch online courses, I see when the mentor perfomed the same actions he got much shorter path:
import { Component } from "#angular/core";
My app work OK for both paths, but I want to know how this happen, just for curious.
Questions:
Why my import path is different?
Is there any config that control this behavior?
Does this effect any behavior of my app?
My enviroment:
Windows 10 Pro x64
Visual Studio Code 1.25.1
NPM 5.6.0
Node 8.11.3
Angular CLI: 6.0.8 (npm install -g #angular/cli)
Angular 6.0.9
Mentor's environment:
Mac OSX
Visual Studio Code
Angular CLI 6.0.0 (npm install -g #angular/cli)
Take a look at the tsconfig.json in your main path.
There is (or can be) shortcuts defined for the imports.
It looks like
"paths": {
"#modules/*": ["app/modules/*"],
"#core/*": ["app/core/*"],
"#shared/*": ["app/shared/*"]
}
With that everything that is in app/modules/MyModule/SomeComponent could be imported as #modules/MyModule/SomeComponent
warm regards
Answers
This is just absolute path difference the way visual studio works is it has the node_modules under the project folder added to your workspace ,so it will suggest you absolute path for the node_modules ,in your case #angular/core. In the tutorials you see or generally we just provide the #angular/core import because at runtime angular complier will resolve the path to absolute path ie..,'../../../node_modules/#angular/core'.
There is no config control over to explicitly define this ,its rather the angular compiler behavior or the way angular ecosystem is built because post compilation all he modules gets invoked and injected on the main component.
No it wont affect any behavior of your app.
I'm pretty new to Node and i'm trying to use Susy grid but get this error
ERROR in ./node_modules/css-loader!./node_modules/sass-loader/lib/loader.js!./scss/waterbottle.scss
Module build failed:
#include gallery(1 of 2);
^
No mixin named gallery
I installed Susy and sass-loader with this command
npm install sass-loader --save-dev
and imported Susy in my .scss file like this
#import "~susy/sass/susy";
I've tried changing this path with no luck. I shouldn't have to do that according to their website.
My project file structure
It seems Webpack is locating the Susy file correctly, but somehow won't recognize it's mixins.
You likely installed Susy3 without reading the changelog. Susy3 no longer has a gallery mixin. Check the susy3 intro and documentation for more details. Susy2 will be maintained for the foreseeable future, if you want to stay with that.
I already work on an Angular 2 project and so far GMap and Chartjs works.
But now i have the problem that if i include an Accordeon it doesn't get formatted properly.
I included primeng and primeui via
npm install primeng --save
npm install primeui --save
and also font-awesome via
npm install font-awesome --save
this is my angular-cli.json
"styles": [
"styles.css",
"../node_modules/primeng/resources/themes/omega/theme.css",
"../node_modules/font-awesome/css/font-awesome.min.css",
"../node_modules/primeng/resources/primeng.min.css",
"../node_modules/primeui/primeui-ng-all.min.css"
],
"scripts": [
"../node_modules/jquery/dist/jquery.js",
"../node_modules/bootstrap/dist/js/bootstrap.js",
"../node_modules/primeui/primeui-ng-all.min.js"
],
and this is the resulting output so far.
resulting output
It would be nice if anyone could bring up some suggestions :-)
I found a solution by my self after a hard research ;-)
The solution is to import the .css files in the global styles.css and not in angular-cli.json
This is my new styles.css-file
/* You can add global styles to this file, and also import other style files */
#import url('../node_modules/primeng/resources/themes/omega/theme.css');
#import url('../node_modules/primeng/resources/primeng.min.css');
#import url('../node_modules/font-awesome/css/font-awesome.min.css');
And this is my new output
So maybe, if someone has the same fault this will help.
I have made a few simple reusable react components and wanted to know the correct way to include a dependency to react in my package.json for publishing with npm.
I am currently doing this:
Assuming my component will use the most recent version of react and I have tested and it works with that version. e.g. 0.13.3
"peerDependencies": {
"react": "^0.13.3"
},
For reusable components:
Put a react dependency in both peerDependencies and devDependencies.
Never put a react dependency in dependencies.
peerDependencies specifies which version(s) of React your reusable component supports/requires. When using npm 2 this also adds React to the list of modules to be installed, but this is no longer the case with npm 3.
devDependencies ensures React will be installed when you run npm install while developing your component, or when running tests on Travis or similar.
Putting react in dependencies will cause multiple versions of React to be installed if somebody uses your component but has a different version of React in their own package.json - having multiple versions of React not only bloats the build, but also causes errors when different versions try to interact.
The selected answer is definitely the prescribed approach here however I've started favoring the use of inversion of control as opposed to relying on npm peer dependencies for my libraries dependencies and its served me well.
Libraries are easier if you build them functional. It seems to be easier to maintain libraries that export a single function which takes in an object with all of their heavy dependencies and export an object containing each of your libraries typical exports.
Library 'injected'
lib/index.js
export default ({ React }) => {
const InjectedComponent = props => (
<p style={{color: props.color}}>This component has no React npm dependencies.</p>
)
/** other stuff */
return { InjectedComponent }
}
Consuming App
app.js
import React from 'react'
import { render } from 'react-dom'
/** Import the default export factory from our library */
import createInjectedComponent from 'injected'
/** Call the factory, passing its dependencies (guaranteed to match what we're bundling) and get back our component */
const { InjectedComponent } = createInjectedComponent({ React })
render(<InjectedComponent color="blue" />, document.getElementById('root'))
If your component only works with a given version of react or some other dependency, you can write some assertions around the version for the React parameter that is passed in. Overall, building libraries in this fashion should be less prone to new build issues appearing anytime version of React is published and will more importantly ensure that you are not causing your library consumers to bundle multiple versions of React and other heavy libraries. This pattern works well with npm link (I generally have 16+ libraries running from npm link simultaneous and experienced issues when I didn't use this pattern).
In your main app I would recommend always splitting out react, react dom and any react lib components you use into a vendor bundle (webpack) and mark it as external in your main bundle so that you do not unintentionally bundle two versions.
You can have react in either peerDependencies or in dependencies. The difference being that with a peerDependencies, react is only installed once for the package using your package. If you put it in dependencies, react will be installed twice, one time for the package using your package, and once time for your package.
React itself seems to favor peerDependencies for some reason. You obviously don't want two separate versions of react in your Javascript bundle (which happens by default if you use dependencies), but that is easy to fix with npm dedupe.
So there's no correct way to do it, both peerDependencies and dependencies work. Using dependencies is more in line with the node/NPM way, but using peerDependencies is friendlier to users of your package that doesn't know about npm dedupe and why it's needed.