Allow users to pass additional IGNORE dirs and filenames from commandline about nue HOT 4 OPEN

Cool! I think site.yaml is a better place than command line.

from nue.

@tipiirai Perhaps tag this issue with a label : requires-documentation <-- or similar, and we keep it open until the documentation is updated? (after the PR is merged I mean) Since we can get that in now, and update docs later.

from nue.

Update
I've run a basic test on cloudflare and this doesnt appear to be interfering with cloudflare pages "functions".
I'd feel a lot more comfortable knowing the directory is phyiscally ignored. For now the work around would be to make sure you don't include any markdown files in the folders?

The files inside the functions directory can't be served statically, since cloudflare will try to route requests matching file paths to matching code "handlers" and expect your code to handle them as REST requests. Which will just translate to GET requests that do or do not match any script files. There wont be any handlers matching the request, and I think what happens in that case, is the requests get converted into root requests for / and the paths get ignored.

For example, what I just tested;

I have a cloudflare function code at functions/api/contact-us.js that's hard coded to handl POST's and return json

{ 
  "cnt":1, 
   "message": "hello world" 
   }

When you try to make a GET request to myblog.com/api/contact-us, cloudflare returns the request as if you had made a GET request to "myblog.com".
And when you make a POST request, the cloudflare function handles the POST correctly.

For now there is a workaround, (which is to do nothing) and yes it's messy, but it's a low priority to fix? I might submit a PR to fix it shortly to avoid accidentally causing something to break. leaving it like this feels like big unexpected problem waiting to cause some unexpected pain later when we add some new functionality to fswalk or similar.

The fact that it doesnt cause a problem right now is just a happy co-incidence, and not by design.

There is a real risk that server side artifacts could accidentally be rendered out in some future enhancement and included in .dist/prod. E.g. developer's private readme.md notes etc. That could be quite bad for some devs.

from nue.

I thought of that, but then wondered if site.yaml should kept clean and only contain content matters, so that if you change your tech, the site.yaml shouldnt change. I think that might be a consideration for later, but for now the advantage of using site.yaml is not having to implement another settings strategy. I think that will come soon, (e.g. passing in environment variables from build server) but we can cross that bridge later.

very long way to say, I agree. I'll create a PR that looks for extra settings in site.yaml. Will need to update docs later when docs can be previewed by contributors ... as well.

from nue.