Allow users to pass additional IGNORE dirs and filenames from commandline

[goblinfactory]

Allow users to pass additional IGNORE dirs and filenames from commandline

Likely affected code

nue/packages/nuekit/src/nuefs.js

Lines 71 to 79 in 16b348a

	const IGNORE = ['node_modules', 'package.json', 'bun.lockb', 'pnpm-lock.yaml']
	function ignore(name='') {
	return '._'.includes(name[0]) || IGNORE.includes(name)
	}
	function isLegit(file) {
	return !ignore(file.name) && !ignore(file.dir)
	}

Rationale

• I want to simplify the build steps for using Nuejs with Cloudflare by excluding the /functions directory.
• I can use Nuejs currently as-is but that would mean having 2 different folders for source code, one for website and one for functions.

Yes, I know that sounds sensible, but that's not how Cloudflare works. They expect your "edge workers functions" to reside in a sub folder called /functions, meaning that I'd need to complicate the build step by building a folder, and the copying in the /functions directory post build. While I can do that, it's just more steps for a new person to Nuejs and new to cloudflare to trip over.

• More importantly i suspect it would mean a file copy build step on every edit (tbc). Even if it doesn't it's just unecessary moving parts if the fix is a simple string value to ignore a folder.

• There are some other reasons as well, but this is the simplest explanation for now. I think this will be the first change that will require support user submitted args, and possible a change to cli.js (code block below is truncated, you need to scroll to see the whole method.)

nue/packages/nuekit/src/cli.js

Lines 25 to 62 in 16b348a

	expandArgs(argv.slice(1)).forEach((arg, i) => {
	// skip
	if (arg.endsWith('/cli.js') || arg.endsWith('/nue') || arg == '--') {
	// test suite
	} else if (arg.endsWith('.test.js')) {
	args.test = true
	// command
	} else if (commands.includes(arg)) {
	args.cmd = arg
	// options
	} else if (arg[0] == '-') {
	// booleans
	if (['-p', '--production'].includes(arg)) args.is_prod = true
	else if (['-v', '--version'].includes(arg) && !args.cmd) args.version = true
	else if (['-n', '--dry-run'].includes(arg)) args.dryrun = true
	else if (['-h', '--help'].includes(arg)) args.help = true
	else if (['-v', '--verbose'].includes(arg)) args.verbose = true
	else if (['-s', '--stats'].includes(arg)) args.stats = true
	else if (['-b', '--esbuild'].includes(arg)) args.esbuild = true
	// string values
	else if (['-e', '--environment'].includes(arg)) opt = 'env'
	else if (['-r', '--root'].includes(arg)) opt = 'root'
	// bad options
	else if (opt) throw `"${opt}" option is not set`
	else throw `Unknown option: "${arg}"`
	} else if (arg) {
	if (opt) { args[opt] = arg; opt = null }
	else args.paths.push(arg)
	}
	})

Tests

New e2e test will likely go here, to test that when ignore values are provided, that the correct folders are ignored

https://github.com/nuejs/nue/blob/16b348a79a25c72ab3107ba0f50fd1ce56818d36/packages/nuekit/test/nuekit.test.js

[goblinfactory]

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.

[tipiirai]

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

[goblinfactory]

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.

[goblinfactory]

@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.