After installing BackboneJS, jQuery etc I have a very large bower_components directory.
├───.idea
│ ├───runConfigurations
│ └───scopes
└───app
├───bower_components
│ ├───backbone
│ ├───jquery
│ │ ├───dist
│ │ └───src
│ │ ├───ajax
│ │ │ └───var
│ │ ├───attributes
│ │ ├───core
│ │ │ └───var
│ │ ├───css
│ │ │ └───var
│ │ ├───data
│ │ │ └───var
│ │ ├───effects
│ │ ├───event
│ │ ├───exports
│ │ ├───manipulation
│ │ │ └───var
│ │ ├───queue
│ │ ├───sizzle
│ │ │ ├───dist
│ │ │ └───test
│ │ │ ├───data
│ │ │ └───unit
│ │ ├───traversing
│ │ │ └───var
│ │ └───var
│ └───underscore
├───css
└───js
What is best practice to reference these? e.g directly, Grunt task to copy bits to the main app, or put the bower_componects inside the ~/app directory?
Don't copy them over to your app - that completely defies the intent of a package manager like Bower! By doing so, you'd take control over these files away from your package manager - and then you're left in the same state as before, manually having to copy over files every time with an update of these dependencies.
Just reference the files inside the bower_components/ directory directly (in your HTML, most likely). If you don't like that location or name, you can have bower put your components some place else, see .bowerrc doc: http://bower.io/docs/config/
I can think of a use for only using specific files from your bower_components directory - but only at build time:
If you write a grunt task that runs only at deploy time and strips away all unused files from the bower_components directory, that of course makes sense and does not go against the idea of a package manager, because it only happens on each deploy, a point when the package manager has no responsibilities.
The only problem you might get with this approach is if you have it end up copying files over to a different directory - because then you'd have to change the references to all files from bower_components before deploying, too. The easy solution is to not duplicate files, but instead, only delete the ones you don't need.
Just leave them in bower_components and refer proper files inside your index.html file. You can do this manually, or use tools like grunt wiredep to do this for you automatically.
Related
For example, let's say we have the following "clean architecture" project structure:
.
│ README.md
│ package.json
│ ...
│
└─── src
│ │ app.js
│ │ app.test.js
│ │ ...
│ │
│ └─── entities
│ │ │ foo.js
│ │ │ foo.test.js
│ │ │ bar.js
│ │ │ ...
│ │
│ └─── useCases
│ │ │ useFooAndBarToBaz.js
│ │ │ ...
│ │
...
How could a test be written to enforce the architectural concept that Entities should not have outward dependencies? IE: no file in the /entities directory should import and use any classes, functions etc found in another directory (/useCases directory in this example).
If possible, I would like to use Jest to write the test(s) (ideally in app.test.js to test the whole /entities directory, but if that's not possible then in foo.test.js to test the content of foo.js, etc etc), but I don't see anything glaringly obvious in the Jest docs about testing file imports.
There may be alternative ways to go about this (can Jest be used in combination with a bash script to walk the directories or something?), so I'm open to ideas.
I believe what I'm asking is impossible, but I'm not terribly familiar with JavaScript and Yarn nor their possibilities so I'm asking as a longshot.
But with my project, I'm getting errors with xmldom versions below 0.7.0:
┌───────────────┬──────────────────────────────────────────────────────────────┐
│ moderate │ Misinterpretation of malicious XML input │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package │ xmldom │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Patched in │ >=0.7.0 │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ expo-linking │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path │ expo-linking > expo-constants > #expo/config > │
│ │ #expo/config-plugins > #expo/plist > xmldom │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info │ https://www.npmjs.com/advisories/1769 │
└───────────────┴──────────────────────────────────────────────────────────────┘
I realize that I can resolve dependencies to higher versions using resolutions in my package.json. However, part of the problem with this dependency is that xmldom is now published as #xmldom/xmldom.
So, beyond just resolving a dependency to a different version, is it at all possible to resolve it to a different package?
React solution is showing one high vulnerability in npm-audit due to Denial of Service in react-svg-loader version 3.03 due to css-what.
What is the possbile solution of the issue?
Issue is as shown below:
───────────────┴──────────────────────────────────────────────────────────────┘
┌───────────────┬──────────────────────────────────────────────────────────────┐
│ High │ Denial of Service │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package │ css-what │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Patched in │ >=5.0.1 │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ react-svg-loader │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path │ react-svg-loader > react-svg-core > svgo > css-select > │
│ │ css-what │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info │ https://npmjs.com/advisories/1754 │
└───────────────┴─────────────────────────────────────────────────────────────
I tried replacing react-svg-loader with https://www.npmjs.com/package/svg-react-loader. It does the same thing only we need to change the package and web pack config. It does not have any vulnerability as of now.
I'm building an in-browser MVC application which will eventually run on a mobile device via PhoneGap. The app will communicate with the API server but will otherwise be completely independent. When I develop standard server-side MVC applications in Rails, the models, views, and controllers are separated into distinct files and directories. What's the standard practice with in-browser MVC apps? Are the MVC components usually defined within a single JS file, or are they usually separated out?
During the development phase, yes javascript files should be separated and well documented..
You can use requirejs to load your modules/views/collections separately.
Here is a great tutorial about Asynchronous Module Definitions (AMD). It's mainly about how you would organize your application using modules. I suggest you read it.
Below is the sample project structure the tutorial's author uses:
├── js
│ ├── libs
│ │ ├── jquery
│ │ │ ├── jquery.min.js
│ │ ├── backbone
│ │ │ ├── backbone.min.js
│ │ └── underscore
│ │ │ ├── underscore.min.js
│ ├── models
│ │ ├── users.js
│ │ └── projects.js
│ ├── collections
│ │ ├── users.js
│ │ └── projects.js
│ ├── views
│ │ ├── projects
│ │ │ ├── list.js
│ │ │ └── edit.js
│ │ └── users
│ │ ├── list.js
│ │ └── edit.js
│ ├── router.js
│ ├── app.js
│ ├── main.js
│ ├── order.js
│ └── text.js
└── index.html
For the validation/deployment phase, use a grunt-like tool to launch automated tasks. Such as concatenating and minifying javascript files into a single one. (It takes around 30 seconds depending on how you've configured it)
Here is an example of a grunt file.
I am trying to work out the best directory structure for a small Dojo application (it's a basic booking system).
I am just about finished writing login/registration.
Here is what I have now:
.
├── app
│ ├── client
│ │ ├── JsonRest.js
│ │ ├── lib
│ │ │ ├── defaultSubmit.js
│ │ │ ├── globals.js
│ │ │ ├── globalWidgets.js
│ │ │ ├── Logger.js
│ │ │ └── stores.js
│ │ ├── login.js
│ │ ├── main.css
│ │ ├── main.js
│ │ ├── register.js
│ │ ├── rrl.css
│ │ ├── TODO.txt
│ │ ├── validators.js
│ │ └── widgets
│ │ ├── _AjaxValidatorMixin.js
│ │ ├── AlertBar.js
│ │ ├── AppMainScreen.js
│ │ ├── BusyButton.js
│ │ ├── css
│ │ │ └── AlertBar.css
│ │ ├── Dashboard.js
│ │ ├── LoginForm.js
│ │ ├── RegisterForm.js
│ │ ├── SearchPage.js
│ │ ├── StackFading.js
│ │ ├── _StackFadingMixin.js
│ │ ├── TabFading.js
│ │ ├── templates
│ │ │ ├── LoginForm.html
│ │ │ ├── RetypePassword.html
│ │ │ └── SearchPage.html
│ │ ├── ValidationEmail.js
│ │ ├── ValidationPassword.js
│ │ ├── ValidationUsername.js
│ │ ├── ValidationWorkspace.js
│ └── server
│ ├── AppErrorHandler.js
│ ├── auth.js
│ ├── db.js
│ ├── globals.js
│ ├── node_modules
│ │ ├── express
│ │ ├── jade
│ │ ├── mongodb
│ │ └── mongoose
│ ├── public
│ │ ├── app -> ../../client/
│ │ └── libs -> ../../../libs
│ ├── routes
│ │ └── routes.js
│ ├── server.js
│ ├── test.js
│ └── views
│ ├── index.jade
│ ├── login.jade
│ └── register.jade
├── libs
├── build-report.txt
├── dojo -> dojo-1.7.1
├── dojo-1.7.1
│ ├── app -> ../../app/client
│ ├── dijit
│ ├── dojox
│ ├── dojo
│ └── util
└── dojo-1.8.0
├── app -> ../../app/client
├── dijit
├── dojox
├── dojo
└── util
The idea behind it is that:
the "app" directory will be in a git repository somewhere (it's about time I make one, actually). It has the directories "client" (all the client-side code) and "server" (the node code).
In "libs" I will add things like dgrid, etc. I also noticed that Dojo 1.8 can be loaded within node (!). I will play with this later -- exciting!
Now, here you can see that I basically used symbolic links to make things work.
SERVER side: Under "public", I had symlinks to "app" and "libs". That way, I can access, from HTML, things like /libs/dojo/dojox/form/resources/BusyButton.css, or (important!) /libs/dojo/dojo/dojo.js and /app/main.js (which then instances AppMainScreen with a simple require(["app/widgets/AppMainScreen" ], function( AppMainScreen){ ...
CLIENT side: I have a symlink to the latest Dojo (my boilerplate still has a problem with Dojo 1.8, so I am still using 1.7 for now). However, in order to make this work within the app:
require(["app/widgets/AppMainScreen" ], function( AppMainScreen){
I have a symlink to "app" within Dojo.
Now: I realise the basics (I think the symlink to "app" within Dojo is solved by simply using DojoConfig, for example). But... well, this is my current 100% unoptimised, never built tree.
I can ask you guys give me the tick of approval for this tree? Will it work once I start "building" things? (I am still miles away from doing it, but I will eventually otherwise my [pregnant] wife will go crazy!). Avoiding that symlink to "app" is one of the things I think I should do (but then again, do I need to?).
Thank you!
Merc.
While not being a fan (nor knowledgable at all) of node, it looks to me as there's a huuge javascript library :)
I'd suggest You should really consider making a buildprofile and use the prefix key to set the location of your scripts. As result of a build, you would automatically get an 'app' folder coexisting with dojo,dijit,dojox.
Actually, i would suggest that once there is a separate repository for your dojo application layer, simply do the checkout within the SDK root, e.g. :
wget download.dojotoolkit.org/dojotoolkit-1.7.2-src.tar.gz -O djsrc.tar.gz && tar xfz djsrc.tar.gz && rm djsrc.tar.gz
cd dojotoolkit-1.7.2-src/
svn checkout http://example/mylibrary app
sh utils/buildscripts/build.sh --profile app/package.profile --release /var/nodejs/docroot/lib/
There is no harm at all in developing your app.widgets somewhere else then in your main document root (/lib). You could simply setup one global variable that tells loader where to look.
If built, nothing should be nescessary, but as far as your current tree goes, try something like this
<script>
var isDevelopement = true;
var dojoConfig = {
packages : (isDevelopement) ? [ name: 'app', location: '/app/client/' ] : []
}
</script>