Feb 08 2018 09:33 AM
Every time I create a new Web Part using Yeoman (yo @micrsosoft/sharepoint) in NPM, I get a huge project including tons of node_modules. The folder adds up to almost 300. I have tested adding web parts under an existing application, however when you run gulp serve it seems to compile every web part under the parent.
Do most people just expect to have all of the node_modules for each web part they create, or is there a better development environment method to consider. Can I set my node_modules folder to be global somewhere, so whenever I scaffold up a new web part I don't get the mode_modules folder?
Feb 08 2018 11:38 AM
normally when you install a node module you add the -g flag and it puts in the global path rather than the local path.
npm install -g <node-module>
(Caveat - I have not used the SharePoint Webpart Yeoman install, so not sure of the behavior, but have done plenty of nodejs).
Feb 08 2018 12:11 PM
Thanks Stephen. Yes, I have read in Node.js you can customize the installation of various nodes that you need, however seems like this Yoeman generator just spits everything out! The Visual Studio method of developing the SPFx framework may not have the same behavior.
Feb 11 2018 08:10 AM
Feb 13 2018 06:12 AM
Thanks Joel. I have seen where some people include all of their web parts in one project. I think that it might be worth grouping my web parts into separate projects, vs putting them all in "one project". I like the idea of being able to use one node_modules folder for all of them, however I don't want that project to get corrupted from Node JS. I think that with a good back up and versioning tool, I can always jump back if all things break on me for some reason.
Feb 13 2018 06:54 AM
Yes, version control will give you the option to roll back if you introduce breaking changes. Git is amazing!
In terms of grouping the web parts, there isn't a right or wrong answer on my opinion. It will depend on what you are trying to achieve. For example, if I'm creating a web part that can potentially be reused for a different project, I will create that web part in isolation or grouped with other reusable web parts. Although, if I'm creating client specific web parts, that won't be reused on a different project (they may have business logic specific to that client for example) I would group them together.
Back to the node modules folder, if you are creating web parts in separate projects, I would again not recommend trying to use a shared node_modules folder across different projects as each project will start with the same dependencies, but evolve in different ways over time. Having a node_modules folder per project (and local to the project) is best practices and the default behavior.
But, if you still decide to give it a go, please post back here your findings as I (and possibly others) would be interested to know if that worked well
Feb 13 2018 07:05 AM
Thanks Joel!
Switching gears here a little bit, have you or any of your colleagues ever tried to add "Custom CSS" to a modern site by using a new SPFx Extension? From what I understand, creating and adding Extensions in your APP catalog creates global "customization" to your site, vs having to add a custom web part to every page.
I have some custom branding I want to add to my site that would affect the overall look and feel, and I know that while Microsoft does not recommend much, if ANY custom branding to modern pages (which is a bit ridiculous in my opinion). I was thinking of using an Extension to add a custom CSS file, which could be easily updated on the fly. Also I would love to add some custom JavaScript to the site, vs having to add to each page in a Custom Web part. I am sure Microsoft, would not recommend this, however if they are unwilling to provide a solid branding capability, then people will figure out a way around it.
Feb 16 2018 12:23 AM
Hi Fredrick,
The application customizer extension will allow you to add custom code to every page.
You can see a tutorial here, hope it helps
Regarding custom CSS to change the default SharePoint styles, I would also advise to be careful about that as it can easily break by MS changing the HTML or CSS behind it. Remember that SharePoint online changes really fast, and the "safety" of controlled updates for on-prem environments is not an option here. You can wake up in the morning and your styles could be completely broken depending on what you do.
There is a way to override global CSS classes by prefixing them with ":global", but again, do it on your own risk if you feel brave :)
For example, if there was an existing CSS class on the site named ms-styles that you wanted to override, you would need a CSS entry like this:
:global .ms-styles {
...css properties here...
}
Hope it helps :)
Mar 19 2018 08:10 AM
Joel,
I have actually begun developing an extension on a dev Communication template site to change some CSS properties. I have been using jQuery in my extension.. Not sure if this is the best way, however I could not figure out a way to reference a separate CSS files of sorts and make it work.
For example, here are a couple of lines that have worked for me:
$('.ms-siteHeader-siteName').css('font-size', '24px'); $('head').append("<style>.ms-siteLogo-defaultLogo {width: 150px !important;}")
Note that I have had to inject in-lines styles to get them to work. I am not a fan of doing this inline "hackery" of sorts, however it seems the only way I can get the look to change, even if it is ugly. I am hoping that Micrsofot will introduce an Alternate CSS method for the Communication sites soon enough!
Apr 24 2021 01:11 PM