Build for js environment without npm? - javascript

We are currently building our frontend js codebase (angularjs) using nodejs with grunt, which seems to be a popular setup, but we are not happy with this solution. Does anyone have suggestions for a build setup for e.g. linting, minimizing our js, running less, etc (in addition to some custom steps for angular in general and for our application specifically) without using nodejs at all?
I would leave it at that to avoid starting a flamewar, but here are, for context, some of the shortcomings of the current setup in our view:
grunt does not have even the basic functionality of a 1970s build system, like automatically re-building only files that have been modified based on file modification time
npm is causing constant headaches running on our build servers at every build

If grunt does not have even the basic functionality of a 1970s build system, why won't you use a 1970s build system then?
Just use make if that's what you're happy with. It still works fine. There's no reason not to use it if it you're satisfied with how it works.

Related

Other way to share react ts components between projects

I have been looking for a way to mostly share some code between projects specifically for SPFX and fluent ui. We found 3 main ways to do that.
1.
Creating a component library is the way that seemed least complicated cause it uses the same infrastructure and do all building without the need to configure it.
But this adds some issues, we need to built and manually link the solution locally to make it work, this will also work if we put in a repo. so this is mitigated.
The second is that implicitly this will also require the fluent ui and react. Plus having to place it inside a SPFX component library project.
2.
I saw some promise using paths in ts and this works fine while using the ts compiler. It will go to the folder that your proj is referring and build it at calling time. which is great. But it did not work in SPFX.
3.
Another way was to have a post install to sync the folders which seems easy enough but I wonder how practical this is plus how people are doing it, if they are, how.
All I wanted to figure out now is a way to take my component code and share as if they were in a folder of my src or a simple extension of the code. No need to have extra dependencies or build steps, just the code that can be used as a ts/tsx file. ex:
shared lib:
//assuming I have react and fluentui already installed for the project.
import button from 'fluentui';
export const fancyCustomButtom = (props) => {
return (<Button text="Standard" />);
};
src project folder:
import {fancyCustomButtom} from 'shared-lib'
It is fine if it needs to build the files before we can use it but can we do it at build time or when the package is installed? also wouldn't it increase my bundle size by making both module dependent on things already available (react, fluentui)?
Given the way Microsoft have architected the loading of bundles in SharePoint and Teams - I believe an SPFX component library is the best way to share code between different solutions, particularly if you are looking to minimise bundle size...
Imagine you have a library for something re-usable: a form, a set of standard branded components - something of that nature. You could put your shared code in repos and add references to it - either by publishing your own repo publicly or using the npm install git+https://yourUrl syntax; but what effectively happens there is that your code is pulled down in to node_modules for each project, and any referenced module code is included in your bundles. If you have two, three, four or more webparts on the same page - using those same libraries, you're multiplying how many times that code is included on the page.
If you follow Microsoft's guide on setting up a component library project however, your npm link commands allow your types to be recognised in consuming projects without needing to actually include the bundled distribution code. You can deploy your library code once to the App Catalog, and if it's referenced in other solutions -- it's loaded on pages as needed: once.
I have found the development experience to be quite flaky at times, but it does work. When I run gulp clean on my library code, or come back to it after some time, I sometimes find that I need to run npm link and npm link my-project-name again as per the instructions in the above tutorial. Whenever you run gulp build on your library, you should also rebuild the project that consumes the library, either by using gulp build / bundle or by saving a file (if you're running gulp serve). This process works well for developing, and once it comes time to deploy, all you need to do is add a named reference to your library inside package.json and then deploy both .sppkg files to your App Catalog.
In terms of your last question re: bundle size - react is not actually included in the dependencies for an SPFX library project, but you will find it's available to use. When you build your library, if you take a look in the generated javascript in your dist folder, you will see it's listed as one of the dependencies for the webpacked content along with react-dom and ControlStrings. It's on line 1.
office-ui-fabric-react is included as a devDependency thanks to the #microsoft/sp-webpart-workbench package that gets scaffolded with all SPFX projects - and if you check your library's dist javascript, you will see that included components are being webpacked and included in your bundle. I'm not entirely sure if when you pull this code in to your consuming project, whether webpack then tree-shakes to de-duplicate and ensures only necessary code is included: I don't know. Someone else may be able to illuminate us there or provide a more accurate explanation of what's going on... I will update this response if anyone comments to let me know.
And finally, this is more of a personal way of working, but it may be worth consideration:
When developing a library, I sometimes reference it in other projects via a local npm install ../filepath command. This ensures that when I install the library as described, the consuming project installs any necessary dependencies. I'm able to tweak both projects if I need o. When it comes time to deploy, I commit my changes to both projects, deploy my library code to the App Catalog, and then npm uninstall the library from the consuming project and add a reference as described in the above tutorial. When I deploy projects that use my library, they just work.
I recently developed a library that uses pnpjs, in particular the #pnp/sp library that is used to talk to SharePoint. If you look at the Getting Started guide for that library, they expect you to pass a reference to your Application Customizer or Web Part context during setup, or explicitly set things up using a base URL and so forth - and of course, a library doesn't really have a page context of any sort - the whole point of this code is that it's reusable. So that poses a challenge. My solution was to do the setup in the consuming web part(s) and ensure that they pass a reference to the sp object (which is of type SPRest) to any code or components that exist in my library. My library has peerDependencies on those pnp libraries so that the code isn't duplicated in consuming projects. Sometimes you have to think about what your library needs to include in its bundle and what you expect consuming solutions to already have, and maybe find ways to ensure things aren't included that aren't needed.
For example, in the scenario you talk about, you may want to ensure fluentui or office-ui-fabric-react are only devDependencies or peerDependencies for your library. As long as your library and the project(s) consuming your library both use the right version(s) you shouldn't have any trouble, and you can document any pre-requisites with your library documentation. You can check which versions of these libraries are installed per the SPFX version you are currently using ie. SPFX v1.11 or v1.12 etc. Just run npm ls <packagename> to get a breakdown, or check your package.json file.

Why angular 2 need node.js

I don't have experience in front-end but I want to create a simple app using Angular 2.
Why do I need to install Node.js as a prerequisite step? Why does Angular use Node.js?
There are a couple of things that Angular uses Node.js for:
Installing and managing packages. From the Quickstart tutorial:
Angular application developers rely on the npm package manager to install the libraries and packages their apps require. The Angular team recommends the starter-set of packages specified in the dependencies and devDependencies sections.
Compiling the TypeScript used into JavaScript that the browser understands - browsers can't process TypeScript natively and the SystemJS imports used in your code aren't supported in browsers yet:
We strongly recommend transpiling (AKA compiling) to JavaScript during a build phase before running the application for several reasons including:
We see compiler warnings and errors that are hidden from us in the browser.
Precompilation simplifies the module loading process and it's much easier to diagnose problems when this is a separate, external step.
Precompilation means a faster user experience because the browser doesn't waste time compiling.
We iterate development faster because we only recompile changed files. We notice the difference as soon as the app grows beyond a handful of files.
Precompilation fits into a continuous integration process of build, test, deploy.
node.js is required in order to install the library using the node package manager (npm).
It is not required to run an app using angular2, only to build it.
For any modern JS based application, as the complexity grows, the app becomes difficult to manage.
In order to make developing and managing complex applications simpler, there are frameworks such as Angular, React etc. and they provide number of tools for the same.
These tools are linting, scaffolding, running unit test cases, starting web server for local development, minify and creating build for the production use etc.
These tools are based on NodeJS as it is JavaScript only and therefore can be customize as per developers needs.
And that's the reason you need Node.js for Angular2 development.

How to set up an automated testing environment for AngularJS

I have spent hours trying to set up an automated testing environment for my AngularJS applications that I can run from Maven (capturing results in Bamboo)
A Google search reveals frameworks galore, based on Jasmine, Karma and generic JavaScript frameworks.
But for some reason the installation of these never goes as described.
Can anyone just point me to a set of downloads that I can install manually to proper directories, that will just execute my unit tests?
I asked a similar question previously and got down checked and requests to close. If you need to check me down, please leave a reason, as I am besides myself with frustration trying to solve this, and I am sure there many other developers experiencing the same issue
Testing javascript is not a totally mature thing, so there isn't a great diversity of good tools for doing so. Jasmine and Karma are the current best ways of doing that.
Those tools are best managed using bower, which is a nodejs package. So you'll have to install, in this order:
nodejs
npm (node package manager)
bower (using npm)
jasmine and karma using bower
phantomjs, and whatever other dependencies your javascript needs (presumably angular)
Then you can run the tests.
I found this package for maven with some brief googling, but god knows how to set it up:
http://searls.github.io/jasmine-maven-plugin/
There are many tutorials on going through this process. You have to accept that these are currently the best tools for doing this and give it your best shot. If you post more specific issues regarding the 'installation that never goes as described' of jasmine and karma you will get assistance.
you can use for example yeoman or angular-seed. both will require nodejs and optionally ruby. both will set you with phantomjs, jasmine, karma, bower and many more. however i would avoid combining that build with maven. imho it's far from perfect. java tools will never be as good as native js tools for building js project. if you really want to combine the builds then use java only to call nodejs and nothing more

workflow and tools for meteor

I'm about to start digging into Meteor for real (instead of just reading about it). I'm a near-complete noob but I've at least determined I'm going to use Sublime Text as my editor vs webstorm. I know I need a git account (going Bitbucket there). What else?
Are yeoman, grunt, and bower, (and lineman?) which seem like the workflow tools of the day, also necessary for writing a non-trivial app? It seems like Meteor already does a lot of the main functionality of these tools.
Do I need a testing suite like Jasmine (at least to get started?)
Anything else I'm missing? I just want to get everything I need (yes, including a couple good Javascript books) before I start.
You'll need the basic elements you already have (node, npm, git and ruby). You seem to know a little bit about web apps so I'll try analogies.
Yeoman essential purpose is to scaffold, meteor will do a really basic scaffolding for you. If you want to have a more advanced scaffold tool I encourage you to try em : https://github.com/EventedMind/em by Chris matter.
Grunt basic tasks equivalents are handled by the meteor commands (server, livereload, build, deploy...)
Bower is a package manager, I highly encourage you to use meteorite and its repo atmosphere (https://atmospherejs.com/) as your package manager. Actually, meteorite commands (mrt) are going to replace meteor commands in your projects. Eventually, atmosphere and meteorite are going to be fold into the core of meteor. (see meteor roadmap : https://trello.com/b/hjBDflxp/meteor-roadmap)
(note that you can use npm packages to)
All the essential functionalities of Lineman are handled by meteor.
However, some tasks are NOT handled by meteor.
I run the classic compass watch on my sass folder.
A good testing framework for meteor is Laika : http://arunoda.github.io/laika/
To start, you can go to discover meteor : https://www.discovermeteor.com/. For more advanced learning; go to evented mind : https://www.eventedmind.com/
The first thing you want to learn is how to handle iron-router
EDIT
There is now two major resources to start :
https://guide.meteor.com/
https://themeteorchef.com/
Iron router has been replaced by flow router ; there is a guide to use it :
https://kadira.io/academy/meteor-routing-guide
To manage scss :
https://atmospherejs.com/fourseven/scss
The view layer :
React replaced Blaze

JS build tool without node

I am a fan of grunt. But unfortunately, we do not have node and hence the ability to access npm packages in our work environment. I have been creating a HTML5 application using AngularJS+Bootstrap etc. I have been able to start and develop the app using angular seed.
However, my main problem is the build (obfuscation and minification) process for such a project. Since ours is a protected environment, I cannot leverage help of other tools like coffeescript etc. I need some tool which may be as good as grunt, but would be available for download directly.
Any help is appreciated and thank you in advance.

Categories

Resources