Subdirectory path matching is not working

I need to clear the source map file after the build. So, I have used ‘rimraf’ to remove the source file.

rimraf --glob .next/**/*.js.map

The above code is working fine on my local machine but it doesn’t remove the file in the Netlify build.
The below command works fin in Netify but I want to use subdirectory in .next folder.

rimraf --glob .next/static/*.js.map

Please provide any work around for this issue.

@Madhan-Kumarasamy What do you mean by:

Do you mean that while the command with /static/ works, you would prefer to use the ** wildcard?

rimraf mentions that the glob implementation is glob and it has various notes in the documentation regarding the double-star character, you could take a read of those and see if anything jumps out

@nathanmartin I mean, js.map file can be in the nested folders. For this, I have used wildcard(**) in rimraf.

@nathanmartin I have another update for removing the js.map files. As below image, it removed the files in the server folder.


Why it doesn’t take static folder?
Actually it runs after the build, whether that is a problem?

next build && pnpm clean:sourcemap

Netlify doesn’t do anything specific about this. Could you confirm what happens when you say it doesn't take the static folder? Do you mean the map files from that folder are not deleted? Could you share a link where we can reproduce the issue?

@hrishikesh @nathanmartin Just leave static folder, js.map file is not present in that path. Let’s discuss the server folder alone. I think it dosen’t check the nested folder in the .next.

Example folder structure:

.next
   |- server
      |-pages
        |-test.js
        |-test.js.map
   |-base.js
   |-base.js.map

If I execute this rimraf --glob .next/**/*.js.map command in my local machine it removes the test.js.map and base.js.map. But the same command executed in the netlify base.js.map file alone is removed. It doesn’t consider the pages folder.

Please let me know if you need more info.

I just testing this in our build system (with an tree of empty files with the same filenames) and it worked just as you would expect it to:

3:10:45 PM: $ tree .next ; npx rimraf --glob .next/**/*.js.map ; tree .next ; exit 1
3:10:45 PM: .next
3:10:45 PM: ├── server
3:10:45 PM: │   └── pages
3:10:45 PM: │       ├── test.js
3:10:45 PM: │       └── test.js.map
3:10:45 PM: ├── test.js
3:10:45 PM: └── test.js.map
3:10:45 PM: 2 directories, 4 files
3:10:45 PM: .next
3:10:45 PM: ├── server
3:10:45 PM: │   └── pages
3:10:45 PM: │       └── test.js
3:10:45 PM: └── test.js
3:10:45 PM: 2 directories, 2 files

That shows the tree before and after the command npx rimraf --glob .next/**/*.js.map runs. As you can see it did delete both map files. (The exit 1 is just to fail the build as I’m testing command and I don’t actually want to publish anything.)

To summarize, rimraf works the same way in our build system exactly as it does elsewhere. We are just using a slightly modified Ubuntu instance for the build system and there is no reason rimraf would behave differently there. Something else must be happening here.

Would you mind sharing the code for the clean:sourcemap script?

According to the productionBrowserSourceMaps documentation

Source Maps are enabled by default during development. During production builds, they are disabled to prevent you leaking your source on the client, unless you specifically opt-in with the configuration flag.

Ergo running a production build doesn’t create source maps that need deleting. If you want to make doubly sure, in the next.config.js set

module.exports = {
  productionBrowserSourceMaps: false,
}

@luke Strange. It doesn’t work for me in the Netlify build. For this clean:sourcemap script, I’m using the same command rimraf --glob .next/**/*.js.map.

@dig I agree. But I’m consciously creating a source map in production and remove it after the build for other reason :slightly_smiling_face:

Yeah, it’s strange indeed, which is why we would like to know a link to the site or a deploy that shows this issue. Plus, a way to confirm that the files are not being deleted would be great!