Well, this is off to a bad start ^^
That said, I don’t think it’s messy personally 
Ok I’ll fix it 
I’m going to use this package for cross-platform support:
I fixed the thing by just putting ‹ SET › before NODE_ENV ^^
But I don’t know if it will work on other platforms after that
Edit: adding a start script and also npm i in the root package would be handy
No, that’s exactly why there’s a module that handles different platforms 
I’ve pushed it, it should fix it for you!
Btw, when it’s devDependencies, it’s not too serious to install small dependencies for this kind of thing, you just need to make sure these dependencies are not in the production build otherwise it will quickly become heavy.
Indeed, it’s much better all of a sudden ^^
I don’t know, I’m considering putting the « controllers » and « middlewares » folder in an « api » folder. After all, burying things in subfolders isn’t always the best idea…
Yes! Then I’ll configure the root package when there will be the front-end.
Everything must be transparent for the developer and the user.
In development, it will launch the hot reload server for the front-end and back-end.
In production, it will just launch the server that will expose the built SPA.
Yes, indeed, it’s not necessarily the best idea, that’s how we quickly get lost in the mountains of subfolders ^^
Quick question, did you pass the eslint test successfully, I suppose?
Yes, why doesn’t it work for you?
It works locally and on Travis!
By the way, your opinion on the repo might be interesting! For you, is it clean?
Nope, I’m getting a 416 error in my face!
But I suspect VSCode isn’t picking up the correct ESLint config… even though it seems like it should automatically pick up the project’s config
I must be missing something… it’s the first time it’s doing this to me.
Ah, that’s definitely it! Investigate your VSCode config…
Oh well, I found it, thanks Windows
It’s a line break issue, Windows uses CRLF by default while MAC and Linux only use LF, so as all the files were created on MAC, my VsCode misinterprets the eslint rules and shows me line break errors everywhere 
Hello everyone!
I just finished a first version of the database modeling Let me know what you think, there might be things to change/forget. Let me know!
I replied to your PR, we don’t want to disable the rule! It will be a mess otherwise. You need to configure your IDE to handle LF without any issues (it’s in the VSCode settings)
Other news, I have defined the structure of the package.json for internal services in Gladys 4.
Here is an example:
{
"name": "gladys-example",
"main": "index.js",
"os": [
"darwin",
"linux",
"win32"
],
"cpu": [
"x64",
"arm",
"arm64"
],
"scripts": {},
"dependencies": {
"axios": "^0.18.0"
}
}
The module must now specify two additional attributes: « os » and « cpu », to indicate the platforms on which the service runs.
When building Gladys for a platform, NPM will perform the necessary checks to determine if the service can be installed.
- If yes, the service will be installed
- If not, the service will not be installed and will be disabled with a special error code (type « platform_not_compatible »), and therefore not loaded when Gladys starts
These rules:
- Having a valid package.json
- Having « os » and « cpu » attributes in the package.json
Are checked by a battery of tests to ensure that all modules are strict about this.
@MathieuA Okay, I’ve changed a bit the architecture and the way to instantiate the Gladys library and the dependencies.
The controllers now look like this:
I find it clearer, and having all the controllers of an entity in the same file I don’t see the problem, they are so thin the controllers… And I prefer to do dependency injection rather than require here.
Then, another change, the Gladys lib must also be instantiated, so that we can manage the « states » more easily.
Let me explain, before I used to make « shared.js » files to store states shared between several files. It did the job, but well it’s not great, in short I used require() as a singleton provider ^^
Proposal: In the same way as the modules, each service is a function that returns functions (in short, it’s like a class that you have to instantiate)
So to launch Gladys, we do:
https://github.com/GladysAssistant/gladys-4-playground/blob/master/server/index.js
I think we will have a clearer app lifecycle and cleaner state management.
PS: I put « controllers » and « middleware » and « routes.js » in an « api » folder, I find it clearer
If anyone has feedback, I’m all ears 
Ahah I thought you’d answer that! ^^
Except that it’s going to be a mess if you don’t disable this rule instead
Because I looked into it and we can’t configure VSCode to automatically take line endings into account. The only configuration we can do is to specify the line ending when creating a new file. Except that for existing files, the only way is to manually modify them, but this causes false changes for Git that I would have to commit… but it’s a bit silly.
Moreover, I’m not the only one developing on Windows, so there will inevitably be conflicts with others. And when they or I make PRs for new files with Windows line endings, it will certainly cause errors during automated tests or even when it’s on your side!
And honestly, with the few files in the project, I already have over 400 errors during testing on my side, so when development is more advanced, I’ll abandon the idea of running the tests
I looked to see if we could do something with the eslint config, but apparently nothing is planned, it’s either one or the other 
So I thought the best thing was to disable this rule, it’s not like I’m disabling comment verification 
Heyy no panic we’ll find a solution ^^
Isn’t it normal to be consistent throughout the project? All serious open-source projects do that. If after just one day of having a strict ESLint we’re already giving up, we won’t get far.
(I say that because clearly this rule is the least hard to follow; behind it, there are other rules that are much stricter about coding style.)
I looked it up on the internet, and it’s possible to create an .editorconfig file in the Git repo that will indicate to your VSCode that this project has chosen « LF » as the line ending style. It’s a cross-editor file format, so it will also help devs using Atom or other IDEs.
Example from an open-source project:
Can you test that? If that’s it, I’ll put that file on the git.
If that’s not it, I found dozens of topics on the subject; it’s a basic problem, we’ll find a solution
Another issue, it might be your Git configured to replace all LF with CRLF on pull.
I totally agree ^^
But after searching for hours yesterday, it got on my nerves
I didn’t know that one! And it works! I had come across a story about a .gitattributes file too, but it didn’t work. It’s a bit mystical because VSCode still shows the Windows line type at the bottom, but I no longer have errors 
Ah, I tried that too, but it didn’t do anything
But in this case, the editorconfig file works perfectly!
That’s normal!
Basically what happened here is that when you cloned the project, either Vscode or git thought you wanted to convert the project to CRLF, and converted all files from LF to CRLF (that’s not what we want)
So what I would do:
1/ we need to add this famous file to git
2/ you reclone the git, and we see if it’s good or not
- if it’s good, it was vscode’s fault
- if it’s not good, it’s git’s fault, it’s that you have a parameter that says to convert the project to CRLF when pulling (my second link)