Yes, you are correct. Joseph Poon and Tadje Dryja in their Lightning Network whitepaper proposed the SIGHASH_NOINPUT flag to prevent transaction malleability flaw hampering the creation of commitment transaction prior to funding transaction. However, with the deployment of SegWit in 2017, NOINPUT was not longer needed as signatures are not part of the txid construction in a SegWit transaction. Since signatures did not form the part of the txid calculation, it solved the ECDSA signature malleability issue that NOINPUT was trying to solve. Thus SegWit deployment allowed us to create the commitment transaction even before signing the funding transaction.
Lightning Network specs have gone a sea change since that paper was published way back in early 2016. I have tried to highlight below how the parties communicate the signing of the transactions as is today and proposals of the future when opening up a channel with each other.
In the current specs (BOLT 1.0), only one party is allowed to contribute bitcoins to the channel. This simplifies the process of exchanging signatures and creating the commitment transaction prior to the funding transaction. Let us say Alice and Bob wants to open a channel. Alice will broadcast the funding transaction only when she has received Bob's signature for the commitment transaction that she holds. Since Alice is the sole funder over here, she has all ammunition to create the funding transaction after Bob exchanges his funding pub key. She creates and signs the transaction, calculates the txid and then shares it with Bob along with her commitment transaction signature that Bob is holding.
Currently there is a proposal (BOLT 1.1) for allowing both parties to contribute funds to the channel. Both parties help each other to build the funding transaction by sharing the inputs and outputs of the funding transaction with each other that they plan to use to fund the channel. It is important to note that they share all information apart from the signatures for those inputs. Once both of them have shared all the inputs and outputs, the parties have enough information to calculate the funding txid. This is because SegWit transactions signatures are not included in calculation of the txid (as mentioned before). This allows us to build the first commitment transaction even before the funding transaction has been created.
Note: Currently, as is, Lightning Network implementation does not require the NOINPUT flag. But to implement the Eltoo payment construction there is a proposal to introduce SIGHASH_NOINPUT. In a nutshell, Eltoo allows us to get rid of the penalty transactions and reduce a lot of overhead on maintaining the channel states. If you are interested you can read the discussion of this proposal on the Lightning mailing list.
