I am working on a project where the Javascript is becoming more complex, and needs to be tested as part of our automated build.
Now I have got a project structure like shown below:
- root
|- build.xml
|- tools
|- js-test-driver
|- js-test-driver.js
|- js-test-driver.conf
|- src
|- code
|- projectname.web
|- assets
|- javascript
|- my-javascript-files.js
|- tests
|- projectname.javascript
|- my-javascript-tests.js
In my Nant build I kick off Java using then pass it the js-test-driver.js file, with the arguments to use the config file provided. Now I noticed that when I was running it that its config file paths seem to be relative to the js-test-driver directory, not the project root directory.
I didnt think this was an issue, and just put the following in my config file:
server: http://localhost:9876
load:
- ../../src/code/projectname.web/assets/javascript/*.js
- ../../src/tests/projectname.javascript/*.js
Now if I run my task in Nant, it starts up the test driver (in Firefox currently) fine but just fails, saying that it cannot find any tests to run, but the thing which I find confusing is that it lists the test directory as:
tests/../../src/tests/projectname.javascript/*.js
And I cannot for the life of me figure out why it is putting this "tests/" before everything... If i put ../../../ in to negate this seemingly hardcoded tests dir, it tells me that the path is not in a valid pattern.
Anyone else had anything similar or know where I am going wrong?
The "tests" folder is always prepended, it's just where jsTestDriver serves its files from. To quote Cory Smith from the jsTestDriver team:
All resources associated with the test
run are served off /test. All static
runner resources are served off
/static
JsTestDriver-1.3.2 has problems with relative paths. The issue has already been discussed and filed as an issue.
Did you try setting the basepath in js-test-driver.conf. It's fairly new and not yet documented, not sure how it's affected by the relative path problems.
basepath: /root/src
Related
I have a TypeScript web application with the following folder structure.
- assets
|- a.png
|- b.png
|- c.png
|- d.png
|- ...
- app.ts
In app.ts, how do I programatically list all the files in assets folder?
I tried the below but it didn't work. And I also thought I may be going down the wrong path because fs is used to access the user's file system, which is not my intent.
const fs = require('fs');
const assets_folder = './assets/';
fs.readdirSync(assets_folder).forEach((file) => {
console.log(file);
});
The issue is related to file location because when you use the typescript after compiling., it'll move to dist/build and it'll look in that directory.
Solution: Copy files/directory from src to dist/build programatically, it'll solve your issue.
Project src
src
assets
images
app.ts
After complie
dist
//<Missing assets>
app.js
When creating javascript-based React projects, installing a Service Worker is just a matter of changing serviceWorker.unregister() to serviceWorker.register() on index.jsx.
With such project structure:
- src
|- index.jsx
|- serviceWorker.js
When this code gets built, the /build folder will look as followed:
- build
|- static
| |- css
| |- js
| |- media
|
|- index.html
|- service-worker.js
This will work fine and will result in the Service Worker being registered properly.
On the other hand, when setting up a project in Typescript, given the same project structure (where the js / jsx files are ts / tsx instead), the /build will look something similar:
- build
|- static
| |- js
| |- bundled-js.chunk.js
| |- bundled-js2.chunk.js
| |- ..
|
|- index.html
So it seems Typescript builds the serviceWorker bundling it with all the other js files.
This will then result in the Service Worker not being registered, with the following error in console:
Error during service worker registration: DOMException: Failed to register a ServiceWorker for scope ('https://example.com/') with script ('https://example.com/service-worker.js'): The script has an unsupported MIME type ('text/html').
The live site with the error can be seen here; The open source code can be found here.
Any idea of what I may be doing wrong?
Any tip is greatly appreciated, thank you in advance!
Ok, looking at your code your using Create React App,. This uses webpack, and it's that what is bundling, it's nothing to do with Typescript, the same would happen for Javascript when it gets bundled.
The problem is overriding the webpack config's is not easy, there is CRACO -> https://github.com/gsoft-inc/craco/blob/master/packages/craco/README.md#webpack-api
But even then it's a little tricky!! You need to tell webpack not to bundle service-worker.js, Also I would take the register bit out of the server-worker, as that can be bundled and wants to be included in your bundle.
The simplest option might be just to compile the webworker separately with Typescript directly. And again, keep the register bit separate inside your normal build.
I'm trying to understand Meteor as I create a project and I find some things a little difficult to understand so far.
1- When they say I can create a server and a client folder, where exactly I am meant to do so? Sibling of .meteor ? And will everything be at client's or server's scope when the app starts or do I have to do something else? If I create a foo.js and a foo function inside it in client folder, can I just call foo() in Meteor.isClient and it will work?
2- I need to create an upload folder so people can upload their stuff (images). So where am I supposed to do this? Plus, how can I get the absolute path to my project and find this upload folder inside?
During my attempts I tried the following:
fs = Meteor.npmRequire('fs');
__ROOT_APP_PATH__ = fs.realpathSync('.');
But __ROOT_APP_PATH__ is .meteor\local\build\programs\server. Quite hidden right?!
3- I saw some people uploading and saving files on MongoDB directly. This is something we usually don't do with relational databases. We move the file to a known folder on a CDN or on our own disk and save the hash or name of that file so we can easily find it. Isn't it encouraged with Meteor + MongoDB? Why would I save the file itself on Mongo instead of moving it to a folder?
not any specific way to do but meteor recommend it doing this way
http://docs.meteor.com/#/basic/filestructure
FOLDER STRUCTURE:
both/ (OR lib/) -- common code for server and client
|- collections/ -- declare collections (e.g Employer = new Meteor.Collection("employer");)
|- router / -- router code(e.g Router.route(..))
client/ -- client side code
|- global/ -- all global variable for client
|- helpers/ -- global helper for client (for all templates)
|- plugins/ -- all the plugins code(if you use any)
|- stylesheets/ -- css / less files
|- templates/ -- all templates
|- home.html -- home template(html)
|- home.js -- home template(js)
public/ -- images/icons/fonts (meteor looking at this file)
server/ -- server code
|- methods/ -- server methods/API (e.g Meteor.methods({...}))
|- publish/ -- publish code from server
this is the basic folder structure for meteor project which i follow. For further reference or Documentation. For any question feel free ask in comments..
I have the following application structure:
application
|- config
|----- config.js
|- routes
|------ api
|-----------router.js
|- Application.js
|- package.json
In /routes/api/router.js module I need to require /config/config.js file and do the following:
require('../../config/config.js');
I found the code above ugly and want to make it more pretty. Also if I move /routes/api/router.js to another folder I have to refactor all requires. What is the best practices to require that modules and is it possible to require config.js from application folder root, something like the following:
require('/config/config.js');
Thanks.
There are a few ways to get around this problem. One is to put all your shared code (like config.js) in a directory under node_modules (using lib here in case you want to have directories other than config in there):
application
|- node_modules
|----- lib
|---------- config
|-------------- config.js
|- routes
|------ api
|-----------router.js
|- Application.js
|- package.json
So then you could require config.js using require( 'lib/config/config.js' ).
Alternatively, you could create a lib symlink in node_modules and link it to lib in your application directory structure:
application
|- node_modules
|----- lib -> ../../lib
|- lib
|------ config
|---------- config.js
|- routes
|------ api
|-----------router.js
|- Application.js
|- package.json
One other alternative, which unfortunately is discouraged by the node docs, is to use NODE_PATH which lets you specify directories that node's require() algorithm should look into. Following the same pattern as above with lib, you would do:
application
|- lib
|------ config
|---------- config.js
|- routes
|------ api
|-----------router.js
|- Application.js
|- package.json
and set NODE_PATH equal to $path_to_application/lib.
UPDATE
Found this great discussion on the topic which includes the options above as well as a few other ones.
The easiest solution is to use path.resolve. If you only give relative paths to path.resolve then it assumes they are relative to the current working directory, i.e. the project root. So all you need is:
const path = require('path');
path.resolve('config/config.js');
require('/config/config.js');
will not work as you are using the root of the system(os) not the root of the application.
var path=require('path');
var root=path.dirname(process.mainModule.filename);
or
var root=process.cwd();
will give you the root of the application. To navigate to config.js
path.resolve(root,'config/config.js)
I have a bit of a strange (but in my view sensible) scenario.
I have a web site, mobile application and maybe going forward a web server all written in Javascript. I have a huge chunk of functionality which is shared between all these systems. This shared stuff would be models, repositories, business logic etc etc.
If we exclude the web server bit as that is a future idea, the web application has a directory structure like this:
app
|- assets
|- models
|- services
|- migrations
|- view-models
|- views
|- descriptors
Now each of these applications is broken down into 2 areas, the core and ui sections, the core is the re-usable stuff such as models, services, migrations and the ui stuff is ONLY used for that application which would comprise of view-models, descriptors (Incase you are wondering views are all html and assets are css, images etc).
Before I was adopting typescript I had a build script which would basically combine all the core files together and minify them. Then it would combine all the UI ones together and minify them. That way in the mobile application I can then just use the my-app.core.min.js and everyone is happy, I am reusing all the re-usable components from the main web application. However I do not need the ui stuff as the mobile UI is completely different to the main web ui, and the web service would not even have a UI going forward.
SO!
With that context explained lets jump back to the Typescript problem at hand. Currently the typescript files are compiled by tsc.exe (version 0.83) via a build script, which just wraps the interaction.
So in the new Typescript world the structure now has a references folder like so:
app
|- assets
|- models
|- services
|- migrations
|- view-models
|- views
|- descriptors
|- references <- NEW ONE!
This references folder is automatically populated by the build script with all local references, so it will trawl through the whole directory tree find all typescript files and build a huge reference file, which is a file full of the reference declarations for local typescript file, to find out more about what im on about look over this question:
Can you create Typescript packages? like c# dlls
So now when I run the build script the following steps happen:
Compiling for Core
Find all *.ts files within the models, services, migrations folders and subfolders
Add all the previous files into an array and also add in the reference files
run tsc.exe with a command like so tsc.exe --out <something>.core.js <previous_file_list>
Compiling for UI
Find all *.ts files within the view-models, descriptors folders and subfolders
Add all the previous files into an array and also add in the reference files
run tsc.exe with a command like so tsc.exe --out <something>.ui.js <previous_file_list>
Now I was expecting this to output 2 files my-app.core.js which ONLY contained the core files, and a my-app.ui.js which ONLY contained the ui files. However they both include everything...
Now after thinking about this, it must be due to the references, as they are both referencing all files, however thats just a compilation dependency in my eyes, not something that needs to be compiled WITH the outputted javascript. In c#/java you would not expect a referenced dll/jar to be compiled into your outputted dll/jar, its just a runtime dependency which is required.
I have tried having 2 separate reference files, one for core and one for ui, but as the ui will depend on core I get same problem, although at least this way the my-app.core.js is devoid of any ui related guff.
So is there a way to have references but NOT have them be outputted into the generated javascript files?
You can accomplish this by generating definition files for your TypeScript files:
tsc --declaration FileName.ts
In your build script do this for each TypeScript file and use the generated FileName.d.ts as the reference instead of FileName.ts
I had the following files:
-BusinessObjects
--Product.ts
--Customer.ts
--Order.ts
--BusinessObjects.d.ts
BusinessObjects.d.ts looks like this:
/// <reference path="Customer.d.ts" />
/// <reference path="Order.d.ts" />
/// <reference path="Product.d.ts" />
with Product, Customer, and Order each have a reference to BusinessObjects.d.ts
when I run:
tsc --out combine.js Customer.ts Order.ts
The output only references Customer and Order, Product is not included. When I referenced the *.ts files directly in my BusinessObjects.d.ts file however the combined output did include the unwanted file.