Al: Exclude hidden files when running alc.exe

[hemisphera]

When running alc.exe (standalone or through VS Code), it seems to pick up everything that it finds in the project directory. If there are any .TXT files present in that directory, alc.exe gives the following warning:

warning AL1025: The file at location 'some\random\txt-file.txt' does not match any definition.

In my case it's a file form Mercurial (the SCM we are using). You could exclude all hidden files and files inside hidden folders. And with "hidden" I also mean folders or files that start with a "dot" (eg: .hgignore, .gitignore)

[Kungitoo]

@hemisphera thanks for bringing this up. The whole reason why we check all the files is because some files which are supported in the product like xml definitions of permission sets, webs services and txt file with translations do not have a designated folder. We will have to consider how to improve this scenario

[anzwdev]

Another case when it might be very usefull is control add-ins development. Here is a nice article how to automate sass/less compilation using gulp and vscode tasks https://code.visualstudio.com/docs/languages/css#_automating-sassless-compilation, but unfortunatelly it creates node_modules folder with thousands of files in the root of al extension directory, so it would be nice to tell al compiler to ignore it.

[kine]

It is good even to skip .git subfolder, because when I looked at output of procmon.exe for the alc.exe, I saw that it is searching for the files even in the .git subfolder, and there are MANY folders and files (fortunately with different extensions, thus ignored).

[kine]

Just want to add another usecase when I need to exclude some folder from the compiler:

I am using git and I am used to use sub-modules. It means in one folder inside the project I have another project. E.g. you can imagine it as I have folder for project A, which is depending on project B. This project B is added as sub-module, it means the code is in some specific subfolder. Now, alc is taking all the al files, including the sub-module. This is not good for me, because I cannot use submodules to include depending projects. Solution for me is, to be able e.g. to select in which subfolder I have the code I want to compile, instead searching in all folders from the root.

In many cases I am using mixed projects, where I have AL code, PS code and may be other codes. I can split these things into separate folders, but I do not have tool to limit ALC to one specific subfolder tree.

[Gallimathias]

Sounds to me like we need AL project files like csproj e.g. so that the AL "compiler" links the correct files when packing the archive.

[kine]

I do not agree. I think the whole VSCode is build on another logic than Visual Studio. I like the logic, where is no smething like csproj which must be maintained, it is hard to version correctly, new version of Visual Studio change the structure etc. I only need to be able to set boundaries of the "project" somehow. Like if I put app.json into subfolder, than only the subfolder will be the AL project. Or I can put folder name where the AL objects are. Something like that, lightweight thing. Scanning whole workspace have no meaning (including the .git subfolder).

[hemisphera]

I fully agree with @Gallimathias. It does not have to be a format as complex as .csproj would be, but a compiler that basically just "takes all it can find from a folder" is actually a pretty optimistic approach.

The fact that we already have the app.json, I can imagine something like a JSON array where you include / exclude files and / or folders. Something along the lines of how one specifies files in .nuspec. And if nothing is specified, just include all (as it does now). This way configuration is optional and still pretty flexible.

[kine]

Ok, true is, that if we already have app.json, than we can have something for setting the boundaries. May be not in the app.json, because I see this rather as app metadata, not compiler settings, but may be some al.json to set the compiler values or VSCode prefrences, which I can set in workspace settings like we have for the package cache path (al.packageCachePath). But in this case, please, add same possibility to set the value when using alc.exe directly during CI.

[Gallimathias]

That's exactly what I mean, @hemispherea. Maybe we can look to the JSON configuration files from docfx. I think that including and excluding folders and files is quite well solved there.

[anzwdev]

I would add these settings to app.json as it looks like a project file to me. It already keeps list of dependencies and paths to logo and screenshots images, so we could have another list of paths to folders/files that should be included or excluded from compilation.

[AbsolutelyFreeWeb]

why not just look at the file or folder properties? Hidden file = do not attempt compiling it.

[hemisphera]

why not just look at the file or folder properties? Hidden file = do not attempt compiling it.

Because that would not really propagate well across repositories and source-control systems.

Besides: not all files that I don't want to include in the project, are files that I don't want users to see.

And lastly: I can't remember the last time I saw someone actually _use_ the "hidden" attribute, not to mention letting it pilot things.

[JavierFuentes]

We need this feature too...

Seems there isn't an official folder structure for Extensions Projects and any way of grouping under a "Solution"/"Workspace" under Visual Studio, so, at least __we need to exclude some helper/internal files and folders from compiler and/or from final .app(s) packaging__.

[kevindstanley1988]

I could also use this feature. For apps that include an add-in there is additional files not defined in the addin, that are part of web development(node_modules) that is being analyzed. I think this could be as simple as following the gitignore pattern.

A .alignore file would do just fine, implementing similar logic to the gitignore structure.

.alignore file in the project folder container a list of folders/files to skip.

\folder\*.txt

This would create no additional complexities. Allow it to be source control safe and allow specific ignores on a per subfolder basis.