We Keep Coding

Angular lazy loaded module components with the same name

I have an Agular app with several lazy-loaded modules. These modules each contain some different components which are logically similar but differ in content. E.g. each module may have its own "home" component.
Is it okay to name these components exactly the same?
To me, it seems overly verbose to prefix each with the module name. Especially when the names start to get long, and considering I would like to maintain the balance between concision and readability.
Functionally this doesn't appear to be a problem. Take the following app as an example. It has 2 lazy loaded modules each containing 2 components with the same name as the components in the other module. One component is loaded by the module's route and the other is loaded via its selector in the template of the first component.
https://stackblitz.com/edit/angular-comp-name-test
I understand that this question may be considered as opinion-based but are there any technical reasons why this shouldn't be done? (I am also interested in opinions if someone wants to dm me)

Technically there is no issue, you can use the same name. Like I have many modules having dashboard as each respective module's component. As long as you properly import it, its fine.
But for larger apps sometimes when auto importing it can import pointing to different 1 then the one required. This happened with me once, I had add and list component in 2 different so while auto importing the url was pointing to the wrong one.
So for just the sake of clarity its nice if you keep different name like prefixing it with something so you know it is for this module etc otherwise we can't say it is or is not "good or bad practice".

Hey you can use import aliases in the tsconfig.json paths
"paths": {
"#modules": "app/test-mod(?:\.\d+)?"
},
You can use regex to match the file end names so that if you have more than one folder you can just name them like file1, file2, file3 and son on the match them in the import using
import('#modules/innerfolder/mymodule.ts')

I have been working on a project with 5 lazy loaded modules having millions of components in their sub folder with same components names.
The good reason or the problem faced by me in while in the development only is while importing the components the auto import does some time imports component from different module and that way I have been facing confusion and getting development done some time with wrong components.
But this has happened 2 times after then I was very safe while importing components

Why does a Cordova project have identical copies of index.js?

I included a lot of background information to help you answer this question, however you can skip down to the heading called 'Questions' to skip to the main point.
Background
I'm new to using Cordova, and I'm new to an existing Cordova project I want to further develop. As a result, when I look at the project files, I am not sure what are choices made by the previous developers and what are choices made automatically by Cordova. I suspect that Cordova generates a lot of files that are not created by the application developers because in my case there are over 7900 files including source code and README's, and the application was previously (to my knowledge at least) developed by only one person.
While many questions could be asked from that perspective, I would like to narrow in on a specific question to avoid being too broad. I've noted that are many files within the path structure called index.js.
$ find . -name "index.js"
./platforms/android/app/build/intermediates/assets/debug/www/js/index.js
./platforms/android/app/src/main/assets/www/js/index.js
./platforms/android/cordova/node_modules/balanced-match/index.js
./platforms/android/cordova/node_modules/os-tmpdir/index.js
./platforms/android/cordova/node_modules/concat-map/index.js
./platforms/android/cordova/node_modules/properties-parser/index.js
./platforms/android/cordova/node_modules/elementtree/lib/parsers/index.js
./platforms/android/cordova/node_modules/os-homedir/index.js
./platforms/android/cordova/node_modules/xmlbuilder/lib/index.js
./platforms/android/cordova/node_modules/ansi/examples/beep/index.js
./platforms/android/cordova/node_modules/ansi/examples/progress/index.js
./platforms/android/cordova/node_modules/ansi/examples/clear/index.js
./platforms/android/cordova/node_modules/path-is-absolute/index.js
./platforms/android/cordova/node_modules/brace-expansion/index.js
./platforms/android/cordova/node_modules/sax/test/index.js
./platforms/android/cordova/node_modules/android-versions/index.js
./platforms/android/cordova/node_modules/lodash/index.js
./platforms/android/cordova/node_modules/cordova-registry-mapper/index.js
./www/js/index.js
./node_modules/objectorarray/index.js
./node_modules/es-abstract/index.js
./node_modules/es-abstract/test/index.js
./node_modules/isexe/index.js
./node_modules/balanced-match/index.js
./node_modules/object-keys/index.js
./node_modules/object-keys/test/index.js
./node_modules/has/src/index.js
./node_modules/has/test/index.js
./node_modules/semver/test/index.js
./node_modules/string.prototype.trim/index.js
./node_modules/string.prototype.trim/test/index.js
./node_modules/cordova-plugin-file/src/blackberry10/index.js
./node_modules/jsonfile/index.js
./node_modules/fs-extra/lib/ensure/index.js
./node_modules/fs-extra/lib/remove/index.js
./node_modules/fs-extra/lib/move/index.js
./node_modules/fs-extra/lib/output/index.js
./node_modules/fs-extra/lib/copy-sync/index.js
./node_modules/fs-extra/lib/fs/index.js
./node_modules/fs-extra/lib/empty/index.js
./node_modules/fs-extra/lib/index.js
./node_modules/fs-extra/lib/path-exists/index.js
./node_modules/fs-extra/lib/copy/index.js
./node_modules/fs-extra/lib/move-sync/index.js
./node_modules/fs-extra/lib/json/index.js
./node_modules/fs-extra/lib/mkdirs/index.js
./node_modules/concat-map/index.js
./node_modules/elementtree/lib/parsers/index.js
./node_modules/fs.realpath/index.js
./node_modules/plist/index.js
./node_modules/path-key/index.js
./node_modules/xmlbuilder/lib/index.js
./node_modules/ansi/examples/beep/index.js
./node_modules/ansi/examples/progress/index.js
./node_modules/ansi/examples/clear/index.js
./node_modules/cordova-android/node_modules/balanced-match/index.js
./node_modules/cordova-android/node_modules/os-tmpdir/index.js
./node_modules/cordova-android/node_modules/concat-map/index.js
./node_modules/cordova-android/node_modules/properties-parser/index.js
./node_modules/cordova-android/node_modules/elementtree/lib/parsers/index.js
./node_modules/cordova-android/node_modules/os-homedir/index.js
./node_modules/cordova-android/node_modules/xmlbuilder/lib/index.js
./node_modules/cordova-android/node_modules/ansi/examples/beep/index.js
./node_modules/cordova-android/node_modules/ansi/examples/progress/index.js
./node_modules/cordova-android/node_modules/ansi/examples/clear/index.js
./node_modules/cordova-android/node_modules/path-is-absolute/index.js
./node_modules/cordova-android/node_modules/brace-expansion/index.js
./node_modules/cordova-android/node_modules/sax/test/index.js
./node_modules/cordova-android/node_modules/android-versions/index.js
./node_modules/cordova-android/node_modules/lodash/index.js
./node_modules/cordova-android/node_modules/cordova-registry-mapper/index.js
./node_modules/cordova-android/bin/templates/project/assets/www/js/index.js
./node_modules/for-each/index.js
./node_modules/tape/index.js
./node_modules/path-is-absolute/index.js
./node_modules/brace-expansion/index.js
./node_modules/deep-equal/index.js
./node_modules/has-symbols/index.js
./node_modules/has-symbols/test/index.js
./node_modules/shebang-regex/index.js
./node_modules/is-callable/index.js
./node_modules/through/index.js
./node_modules/through/test/index.js
./node_modules/resumer/index.js
./node_modules/resolve/index.js
./node_modules/resolve/test/resolver/dot_main/index.js
./node_modules/resolve/test/resolver/multirepo/packages/package-b/index.js
./node_modules/resolve/test/resolver/multirepo/packages/package-a/index.js
./node_modules/resolve/test/resolver/quux/foo/index.js
./node_modules/resolve/test/resolver/incorrect_main/index.js
./node_modules/resolve/test/resolver/same_names/foo/index.js
./node_modules/resolve/test/resolver/dot_slash_main/index.js
./node_modules/resolve/test/shadowed_core/node_modules/util/index.js
./node_modules/resolve/test/node_path/x/ccc/index.js
./node_modules/resolve/test/node_path/x/aaa/index.js
./node_modules/resolve/test/node_path/y/ccc/index.js
./node_modules/resolve/test/node_path/y/bbb/index.js
./node_modules/resolve/test/module_dir/ymodules/aaa/index.js
./node_modules/resolve/test/module_dir/xmodules/aaa/index.js
./node_modules/resolve/test/precedence/aaa/index.js
./node_modules/resolve/test/dotdot/abc/index.js
./node_modules/resolve/test/dotdot/index.js
./node_modules/function-bind/index.js
./node_modules/function-bind/test/index.js
./node_modules/shebang-command/index.js
./node_modules/minimist/index.js
./node_modules/cordova-plugin-network-information/src/blackberry10/index.js
./node_modules/cross-spawn/index.js
./node_modules/es-to-primitive/index.js
./node_modules/es-to-primitive/test/index.js
./node_modules/strip-bom/index.js
./node_modules/is-date-object/index.js
./node_modules/path-parse/index.js
./node_modules/is-symbol/index.js
./node_modules/is-symbol/test/index.js
./node_modules/base64-js/index.js
./node_modules/node-version-compare/index.js
./node_modules/node-version-compare/test/index.js
./node_modules/universalify/index.js
./node_modules/define-properties/index.js
./node_modules/define-properties/test/index.js
./node_modules/nice-try/src/index.js
./node_modules/defined/index.js
./node_modules/object-inspect/index.js
./node_modules/is-regex/index.js
./plugins/cordova-plugin-file/src/blackberry10/index.js
./plugins/cordova-plugin-network-information/src/blackberry10/index.js
It would be extremely broad and impractical to question what each and every one of these identically-named files are for, and some may be inanswerable if their existence depends on design choices of the previous developers of this project. Fortunately, I can be more specific than that. I have an issue to debug, and with a specific search string related to the bug, I was able to find that specific files named index.js contained that string.
$ grep -ril "<search_string>" .
./platforms/android/app/build/intermediates/assets/debug/www/js/index.js
./platforms/android/app/src/main/assets/www/js/index.js
./www/js/index.js
And to clarify further, while not being the only files returned by grep, these three index.js files were the only files that appeared to be relevant to my bug. I then used cmp to compare these three files, and I found that they're mutually identical (not shown since cmp by default only prints output when there is a difference).
There seems to be some confusion about the importance of ./www/js/index.js, but it also seems to be the case that I should prefer to edit ./www/js/index.js rather than ./platforms/android/app/src/main/assets/www/js/index.js because ./platforms/android/app/src/main/assets/www/js/index.js is automatically generated by Cordova according to this post. This suggest that ./www/js/index.js is not automatically generated, although this still leaves open whether ./platforms/android/app/build/intermediates/assets/debug/www/js/index.js is automatically generated. Given that build is in the path of ./platforms/android/app/build/intermediates/assets/debug/www/js/index.js, I suspect that this is a file automatically generated when the command cordova build android is run. This leads me to the suspicion that I should edit ./www/js/index.js and not the other two of these three files.
Questions
I'm really asking 3 questions in one post, however since their scope and background are nearly identical I would prefer to keep them together for context.
Which of the three index.js should be edited in developing an application with Cordova?
./platforms/android/app/build/intermediates/assets/debug/www/js/index.js
./platforms/android/app/src/main/assets/www/js/index.js
./www/js/index.js
The three index.js files mentioned in Question 1 are identical. Why do each of these identical copies exist?
There are non-identical files named index.js in a Cordova project. Why are they all called the same name if they are non-identical in content?

You should edit /www/js/index.js.
The other two files are created during the build process. A built Cordova app will have all www folder contents inside an android app structure, that's why they are inside /platforms/android/app/src/main/
The other index.js files are there because it's a Node.js pattern

How to exclude a subfolder of compiled resources from a Sonar analysis?

I am trying to integrate Sonarqube analysis into the JavaScript sources of my project. It is a project using Spring components for the back-end, and as a first step, we did the integration of Java sources, without problem at that point.
We are using Sonarqube v5.6.3
The problem I am finding comes with the sonar.exclusions property. Apparently, that property can't exclude a folder that has already been added as sources (see question and answer explaining that exact issue).
I have the following lines in my pom.xml, which are not working properly; and that's understandable according to the aforelinked question:
<sonar.sources>src/main/java,src/main/docker,js-sources</sonar.sources>
<sonar.tests>src/test</sonar.tests>
<sonar.exclusions>**/target/*</sonar.exclusions>
The problem is: the front-end is made of several modules which are compiled one by one under their own /target sub-folder before being deployed all together into src/main/webapp. (They work as regular target folders: when a new compilation is launched, those folders get deleted/recreated.)
Those js-sources/moduleA/target, js-sources/moduleB/target, js-sources/moduleC/target folders are being automatically included as sources, and thus ignored by the exclusions directive. Those target folder still contain a /src subfolder, which makes it hard to use the limited Sonar patterns (full xpath-like selectors are not allowed) to include or exclude only certain paths.
As I don't think that the Sonarqube team was expecting everyone to add each little subfolder one by one (that's why they made patterns in the first term), I am looking for help: How do I exclude those per-module target folders living down the folder-tree inside my sources?
Another possibility would be that it is kind of a bug forcing us to store this config at a Jenkinsfile or even directly in the Jenkins config (at a job level), but I remain unsure and still think that something can be fixed in the way I am declaring the sources and exclusions.

Try
<sonar.exclusions>**/target/**/*</sonar.exclusions>

EDIT : while inclusions are useful in other cases, the accepted answer above is the correct one. I'm leaving mine, which follows, for the record and just as an example of using inclusions.
Try using inclusions rather than exclusions, I've setup a project as close to yours as I could guess from your description and I was able to ignore the target folders of the js-sources modules :
<properties>
<sonar.sources>src/main/java,js-sources</sonar.sources>
<sonar.inclusions>**/*.java, **/src/**/*.js</sonar.inclusions>
</properties>
You can read this as : 'scan all java files no matter where they are, scan only the javascript files that are found within the src of a subfolder of root'

Meteor - How to exclude certain paths from being crawled?

In Meteor, I have installed the spiderable package, which allows the application to be crawled by search engines. However, I want to exclude certain paths from being crawled.
For example, example.com/abc/[path] should not be crawled, whereas example.com/[path] should be.
I am unsure of how to do this. One guess is to include a robots.txt in the /public directory, and use regex as described here. However, the url doesn't contain the #! as it did in this question. Is that relevant?
My current implementation is a bit more complicated, and it's based on the following quote from the package's README.md:
In order to have links between multiple pages on a site visible to
spiders, apps must use real links (eg ) rather than
simply re-rendering portions of the page when an element is clicked.
At the moment, when the page is rendered, I test whether there's a /abc in the root of the path, and then set a persistent session variable. This allows me to make all paths in my pages' links not contain the /abc prefix. When a link is clicked, it will check whether the session variable is set and append to the path in an onBeforeAction() function, which allows the right template to be rendered. In doing so, I am hoping those links won't be visible to the spider, but I am unsure of the reliability of such a method.
tl;dr - How to exclude certain paths from being crawled in Meteor?

It kind of depends on what you're doing with the folders you don't want crawled. If they're just going to be used on the server side, you can use the /private/ folder. If you want them accessible, but uncrawlable, you can build in access to folders with a /.period/ in them, which makes them invisible to Meteor, but you can access via the connectHandlers and webApp properties similar to my answer here.
If you want them to be processed by Meteor as normal (e.g. javascript files) but then be inaccessible to the spiderable package, I'd suggest asking in meteor-core.

Issue with concatenating a few javascript files

This is a complete noob question, but I gotta ask it anyway
I started playing with backbone.js a few days ago and I was really fascinated. As I got over the "ToDo", I started working on a project of my own. Coming from the world of Java, I prefer keeping everything in as many separate files as possible. Therefore, I split my models views, and routers into separate files, into separate folders.
The problem came when I tried to combine those fiels into one single applciation.js file. Again, coming from the Java world, I love when I can automate stuff, and even more, when I can use familiar tools like ant, to setup build processes for my javascript projects.
I got a sample ant build template which concatenates and minifies all the files in an arbitrary order. When it finished, I tried to run my JS app, and not surprisingly, it failed with a bunch of errors. Many of my models and views try to extend each other, others depende on them as components. If they are not defined in a proper order, the app just reaches a point where it is trying to execute extend of an undefined
I know from before that for JavaScript the order is very important, but somehow I was left with the impression that if all the scripts are in one single file, the JS parser will load all the stuff first and then will try to execute whatever is to be executed. Well, my assumption was wrong.
It is possible to list all the files in the specific order I want them, but do I really need to go for such a primitive step? Unfortunately after spending a few hours researching, I couldn't find anything better.
Is it really possible to concatenate JS files, which depend on each other, in an arbitrary order, without them clashing? I guess, the biggest problem is the fact that the extend function is actually being called, rather than each script simply defining and object literal
So, what's the solution?
UPDATE: I just saw that Sproutcore has its own builder. If SC is roughly similar to BB, in the way one creates and extends entities, how does the SC builder work without clashing?

There are many ways to do this, but here's my recipe. I prefix my development files with a number, starting from the one with no dependencies (base "classes", models that will be depended upon from other models, then views using these models, then routers calling those views, etc.).
Then I use uglify-js (available as a node.js library, that you install using npm install uglify-js) to minify all my js in one file (don't know from your question if you use node.js server-side, though). Then I cat *.js | uglifyjs -o min/myfile.min.js. This will send the content of all my .js files (respecting the order of dependencies because of my prefix) to uglify, which will minify it and save it to a single file.
Since I, too, like automation, I have this set up in a Makefile, though I guess it could be done using Ant (not too familiar with it). The relevant part of the Makefile look like this:
TARGET_MIN_FILE = public/js/min/myfile.min.js
JS = $(shell echo public/js/*.js)
public/js/min/myfile.min.js: $(JS)
cat $(JS) | uglifyjs -o $(TARGET_MIN_FILE)
clean:
rm -f $(TARGET_MIN_FILE)
.PHONY: clean
On the other hand, if you go for the asynchronous module definition (AMD) format, you can require() your modules and it will manage for you the dependency loading in the correct order (see Require.js for more info), as mentioned by TheShelfishMeme.

Your "assumption" is only true for var statements and functions of the form function name(a,b) {}. Those two get hoisted to the top of the script (or function block they are in) and are evaluated first.
If your files depend on other files being loaded first, it stands to reason that when you concatenate them they must be in that order in the final file.

Have a look at requirejs. It takes some time to set up but it should help you with your problem.
This article should help with the implementation.