Includes and layouts render files with writeToDisk: false

[thomastorfs]

When using includes or layouts while setting writeToDisk to false, Marko still writes the JS rendered files for these.

Is this a bug? Or is there a way to disable this as well?

[patrick-steele-idem]

Hey @thomastorfs, thanks for reporting the problem. I'm going to see if I can reproduce, but if you could provide more details that would be great.

[patrick-steele-idem]

I suspect you are seeing this issue because there are multiple instances of marko being loaded at runtime and each instance is being configured independently. This could happen if you have different versions of marko being used in your project and that would prevent de-duping from happening when installing the node modules. Do you see multiple lines for marko when you run npm list?

In either case, I decided to make the Marko configuration a true "singleton" by attaching it to the global scope. This may or may not solve your problem depending on which versions of marko are being loaded in your project, but once you are using only the latest version then it should fix the issue in the situation that there are multiple instances of marko being loaded.

[thomastorfs]

Hi @patrick-steele-idem ,

I just tested the compilation process again. I'm running Marko 3.7.1 only (no other versions or duplicates are installed). For some reason the includes still write a separate JS file.

For what it's worth, I'm using Brunch in combination with https://github.com/thomastorfs/static-marko-brunch

Any ideas?

[aaronshaf]

I have having a problem with this bug as well.

[patrick-steele-idem]

@thomastorfs @aaronshaf would either of you be able to share a minimal project to reproduce the problem? I was not able to reproduce the problem. Thanks!

[jasonmacdonald]

Hey Patrick, I'm also seeing this now where layout-use(template) is generating a file system compile of the template, while all other templates are not written to disk. Let me see if I can put a simpler demo together for you.

[jasonmacdonald]

Ok, here's the simplest project I could make that shows the issue. When you first run this, it will create a layout.marko.js, but not a template.marko.js. It shouldn't create either, the compiler option is set to

{ 
   compilerOptions: { 
         writeToDisk: false
   } 
}

https://github.com/jasonmacdonald/layout_generates_file

[jasonmacdonald]

@patrick-steele-idem I've managed to trace it back to requireResolve method in CompileContext but can't seem to understand where to go from there. It seems memberExpression() constructs a call combining require and resolve, but I can't really see what it's doing that would bypass the 'marko/node-require' which should see the flag for writeToDisk.

[jasonmacdonald]

Ok, further digging it seems layout.html in my example gets loaded by a helper, which uses loader/index files loadFile() method which does not get passed the options we passed in through require('marko/node-require').install({config...});. It only sees options that were set using the markoCompiler.defaultOptions.

Looking in the helper, the only thing the helper passes to load is the path, no options.

I confirmed that switching to setting global.__MARKO_CONFIG does stop layout.html from being written to disk.

So it seems the bug is only when you set compilerOptions via the config on node-require.

My suggestion would be to have the install(config) on node-require actually set the global.__MARKO_CONFIG so it acts as expected in all loading scenarios. Just my $0.02.

[patrick-steele-idem]

@jasonmacdonald thanks for digging in and figuring out the issue. I don't see any harm with passing along the configuration provided when calling require('marko/node-require').install({config...}) to require('marko/compiler').configure(...) . This would make the configuration truly global as expected.

NOTE: You should not be referencing global.__MARKO_CONFIG in your code since that is an implementation detail that could change in the future.

[jasonmacdonald]

@patrick-steele-idem I figured as much, it was more just to test if that would work. :)