Hello,
Im excited about the new require syntax for SF 5.6
Feature: Add support for require('./xyz') syntax and shared typings between scripts in a package.
Feature: Implement relative code paths (respecting package folders) in require('./xyz') and require('../../blabla') syntaxes.
Im trying to implement this however Im struggling with the syntax.
I have two scripts in the same folder, Test Export and Test Require
In Test Require my code looks like this:
const test = require('Test Export')
And when I run it I get this error:
Command 'Test Export' not found (Test Require: Line 1)
Furthermore, when I try syntax like this:
const test = require('./Test Export')
I receive this error:
Local command path in './xxx' format is not supported in this context - command id
Could someone please point me in the right direction to utilize this new feature?
Thanks
Linked from:
- OOwen Granich-Young @Owen_Granich_Young
Will! Wish you had been at the hangout today, @Kitch just showed us this. I think the thing you're missing is that the
require
needs you to require a local package ID not the name of the packageHere's the example Kitch used today in the web hangout.
Your Modules in here
your Package ID here and use those elements in this script.
- WWilliam Harp @William_Harp
Thanks Owen! I didn't know there was a hangout. I'd love to make it to the next one!
Thank you for sharing. Ive been using require(packageID) and this syntax for awhile now, but I got the impression the new feature would allow for more traditional JS syntax where you can require a file name (That would be really nice and readable!)
- OOwen Granich-Young @Owen_Granich_Young
ahhhh I see I seeee. Yeah I just learned about this at all today and was like 'YOU CAN DO THAT?' Geez. Yeah for the most part every Wednesday at 11am https://us02web.zoom.us/j/82199380481?pwd=NGRpd1FJWVJab013aWZ4TU9NVS9QZz09&fbclid=IwAR3erNk4Ag7siQK3yFCrqFmv5jBLXnFQcPPYMtbJ8vMPftwv5jq8lOGXSK4#success always a good time.
Hope to see ya at one soon,
Owen
- In reply toOwen_Granich_Young⬆:
Nathan Salefski @nathansalefski
So this is how you implement functions you have already written into future scripts?
Chris Shaw @Chris_Shaw2024-02-21 22:22:07.136Z
yep
- In reply toOwen_Granich_Young⬆:
Christian Scheuer @chrscheuer2024-02-22 02:00:04.590Z
This is indeed how "require" has worked so far.
The newer syntax automatically takes your typings over from the require'd module. I just noticed we haven't properly enabled this syntax for normal scripts in 5.6.0 - a fix is coming in 5.6.1 that allows the following:
Let's say you create a reusable "module" script and call it "TestModule" (name your command this in the package):
/** * @param {string} str * @param {number} num */ function test1(str, num) { } /** * @param {number} num1 * @param {number} num2 */ function test2(num1, num2) { return num1 + num2; } module.exports = { test1, test2, };
Then a script in the same package can require this module - and the type syntax for each function will automatically be brought over:
Even better, you'll be able to command+click on "test1" to be taken directly to its definition in the other file :)
5.6.1 should come out tomorrow with this update.
- WWilliam Harp @William_Harp
This is sensational! I use require in nearly all my commands and this is going to be so nice.
Christian Scheuer @chrscheuer2024-02-22 02:35:53.176Z
Yay, right?! It's so good. Here's the early direct download link for 5.6.1 :)
https://downloads.soundflowcdn.com/5.6/5.6.1/a73f23239e5f6da2/SoundFlow_5.6.1.pkg
Dustin Harris @Dustin_Harris
I notice the parameters get passed but not their types (in your example above,
{string} str
becomesstr: any
). Is that a limitation for the time being or a bug? 😍Christian Scheuer @chrscheuer2024-02-22 15:55:31.897Z
I hadn't noticed that. I don't know why that's happening - this part is taken care of entirely by Monaco, so I'm not sure there's much we can do.
Christian Scheuer @chrscheuer2024-02-22 15:56:03.965Z
Honestly, it might have been me trying to remake the example too quickly and forgetting to add the typings in the module. It might work
Christian Scheuer @chrscheuer2024-02-22 16:11:23.102Z
We figured it out. There needs to be an empty line before the first
/** ... */
block in a script, so this is whytest1
was not properly getting its typedefs.
- In reply tochrscheuer⬆:
Christian Scheuer @chrscheuer2024-02-22 16:42:51.061Z
5.6.1 is also publicly available now from my.soundflow.org :)
- In reply tochrscheuer⬆:
Chris Shaw @Chris_Shaw2024-02-22 03:24:36.013Z
Wait…so you no longer need to use the local package ID and just use
require('./moduleScriptName')
?
I assume then that the module script name must use camel case…
🤯Christian Scheuer @chrscheuer2024-02-22 16:43:39.641Z
Just avoid special characters like slashes and you should be fine :)
- In reply toChris_Shaw⬆:
Chris Shaw @Chris_Shaw2024-02-22 18:24:02.281Z
Ah, so no need to use camel case: the require statement is a string - just avoid weird / special characters
Christian Scheuer @chrscheuer2024-02-22 18:51:26.517Z
Yea, it's a file path as a string. So generally file path valid characters should be supported. But no need to go crazy ;)
- In reply tochrscheuer⬆:
Ryan DeRemer @Ryan_DeRemer
So far so awesome! Running into one obstacle. When I have a module in the root of the package, and a requiring script in a folder (in the same package), the requiring script can't find the module. Probably just an adjustment to the path? Tough to show here but hopefully my description is clear.
- WWilliam Harp @William_Harp
Hi Ryan,
You would need to put the name of the folder in the path
Require(‘./YourFolder/YourScript’)
Furthermore, you can “escape” the folder you’re script is in by using the “../“ syntax.
For instance if your script is in a folder name ScriptFolder1, and beside it is ScriptFolder2, you could access scripts from one another like this:
Require(‘../ScriptFolder2/ScriptName’)
Ryan DeRemer @Ryan_DeRemer
Thanks William! I thought this was still SoundFlow-specific. Turns out it's regular JS syntax that I missed out on learning til now lol.