No internet connection
  1. Home
  2. How to

Require Syntax

By William Harp @William_Harp
    2024-02-21 20:51:55.669Z

    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

    Solved in post #7, click to view
    • 22 replies

    There are 22 replies. Estimated reading time: 8 minutes

    1. O

      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 package

      Here'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.

      1. WWilliam Harp @William_Harp
          2024-02-21 21:29:18.009Z

          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!)

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

          2. Nathan Salefski @nathansalefski
              2024-02-21 21:41:29.298Z

              So this is how you implement functions you have already written into future scripts?

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

              Reply2 LikesSolution
              1. WWilliam Harp @William_Harp
                  2024-02-22 02:04:35.177Z

                  This is sensational! I use require in nearly all my commands and this is going to be so nice.

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

                    1. Dustin Harris @Dustin_Harris
                        2024-02-22 06:05:54.611Z

                        I notice the parameters get passed but not their types (in your example above, {string} str becomes str: any). Is that a limitation for the time being or a bug? 😍

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

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

                            1. We figured it out. There needs to be an empty line before the first /** ... */ block in a script, so this is why test1 was not properly getting its typedefs.

                        2. In reply tochrscheuer:

                          5.6.1 is also publicly available now from my.soundflow.org :)

                      • In reply tochrscheuer:
                        Kitch Membery @Kitch2024-02-22 02:47:53.021Z

                        SOOOOOO GOOOOOOD!!!

                        1. In reply tochrscheuer:

                          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…
                          🤯

                          1. Just avoid special characters like slashes and you should be fine :)

                            1. In reply toChris_Shaw:

                              Ah, so no need to use camel case: the require statement is a string - just avoid weird / special characters

                              1. Yea, it's a file path as a string. So generally file path valid characters should be supported. But no need to go crazy ;)

                            2. In reply tochrscheuer:
                              Dustin Harris @Dustin_Harris
                                2024-02-22 05:30:32.361Z

                                Oh wow this is superb!!

                                1. In reply tochrscheuer:
                                  Ryan DeRemer @Ryan_DeRemer
                                    2024-02-23 08:11:33.536Z

                                    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.

                                    1. WWilliam Harp @William_Harp
                                        2024-02-23 14:23:36.977Z

                                        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’) 
                                        
                                        1. Ryan DeRemer @Ryan_DeRemer
                                            2024-02-23 19:32:59.621Z

                                            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.